Question: Which is better: a) Working nights and weekends to meet iteration commitments, or b) Admitting the commitment was too much and working normal hours regardless of the commitment? [Read more...]
Agile pondering: Is it agile to have a “single wringable neck?”
July 23, 2009 by 2 Comments
In Scrum one of the named roles is that of Product Owner. Some people have taken to referring to this position as the “single wringable neck” on a Scrum team. This is because the Product Owner is ultimately responsible for the prioritized product backlog which the team uses as their to-do list to build the product. If the Product Owner does a poor job then the resulting product will not meet customer needs. That scenario leads people to believe the Product Owner should be held accoutable for the failure.
To me this is very short-sighted. The Product Owner has a LOT to do without having this additional burden placed upon them. Because I want to keep this blog entry short I will give 5 reasons why the “single wringable neck” concept has to be left behind: [Read more...]
Agile antipattern: Waiting for all the requirements before starting
July 16, 2009 by 3 Comments
Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.
Remember a few things when you are tempted to get all of the requirements up front:
- Requirements WILL change. In courses I teach the average percentage of requirements which change is 50%.
- Requirements WILL be dropped. We almost always think we can get more done than is possible (or even desirable in many cases). It seems the average percentage of dropped requirements is 25%.
- New requirements WILL come up during development. This too seems to average about 25%.
When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front. Get the requirements good enough to start moving forward. Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt. Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago. This isn’t up to the developers themselves, but the product owners and others who maintain the backlog. Build GREAT products by adapting to changing conditions. EMBRACE change as a good thing, not as an impediment.
Until next time I’m Making Agile A Reality® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.
Making Agile a Reality®
July 15, 2009 by 2 Comments
Today is an interesting day. Back in January 2009 I decided to apply for registered trademark status for the phrase “Making Agile a Reality.” Today I found out that the trademark registration is complete and Agile For All now has a registered trademark. So instead of “Making Agile a Reality™” we will start to use “Making Agile a Reality®.” I am quite excited, but also a bit humbled by this.
I am humbled because I feel having this registered trademark implies being able to deliver upon it’s promise. Agile For All has been doing so since the company was formed, but now it somehow feels a bit different. I know this is silly because nothing really has changed, yet I can’t shake the feeling. I think I LIKE the feeling, it is just different for me.
Now, how to add value for others to this blog post? I think a discussion of why I chose “Making Agile a Reality” as a slogan would help others understand the specific issues I see in the industry, and hopefully help them avoid those issues! [Read more...]
Agile antipattern: Using email as the primary communication tool
July 8, 2009 by 11 Comments
Can I just be short and to the point for this one? I hope so, because that is my intention!
Email is LOW BANDWIDTH communication
Agile teams REQUIRE HIGH BANDWIDTH communication
Do you see a problem?
Agile teams need to communicate in real-time whenever possible. Even the agile manifesto says “individuals and iteractions over …” In other words, one of the primary things about agile is people interacting with each other! Email is not an interaction. It is one way communication because we don’t know when we’ll get a response. We don’t know IF we’ll get a response. In fact, in almost all cases we don’t even know if the intended recipient even received the message!
Don’t fall into the trap of believing email is real-time communication. A team relying on email will pay the price by having misunderstandings which lead to later corrections, and even worse, they will usually miss their commitments.
Until next time I’ll be continuing to tell people to use email ”ONLY when the answer isn’t important for the next 4 days” because anything less isn’t going to be Making Agile a Reality™.
New to agile? What to do when you are behind
July 6, 2009 by 10 Comments
Wow, has it really been more than a month since I posted something on my blog? Ouch! I guess I’ve been busier than I thought. I knew it had been a while, but I thought it was 2 weeks, not a month. For those of you who expect content from me more often, I’m sorry. I’ll try to get back on the 2-3 times per week train.
The good news is during my time away from blogging I found lots of new topics for future posts. In the coming weeks you find postings on different estimation techniques, how the theory of constraints can help agile implementations, using kanban, and a whole lot of other interesting stuff. If you have a topic you want me to cover, please email me using the link near my picture. I’ll start on the blogging train with a quick post on what to do when you are behind! [Read more...]
