Research says management is often the biggest obstacle in the adoption of agile software development. Let's try and raise a new generation of agile managers!

 

 

Monday
Aug022010

Table of Contents Published

I have published the table of contents of the Management 3.0 book. It is a preliminary table of contents, because copy-editing phase has started, which means things can (and will) change. But this should at least give you an idea of what’s to come.

The main body of the book (chapters 4-15) consists of six themes, each described in two chapters. The first chapter in each theme is more "theoretical," while the second chapter is more "practical." For example, the theme "Develop Competence" has a theoretical chapter called "The Craft of Rulemaking," and a practical chapter called "How to Develop Competence."

read more...

Friday
Jul232010

Is the Gantt Chart Useless in Agile Projects?

I’ve written before that I am not an “Agile” nor “agile” developer nor project management expert.  I’ve previously proposed that one by-product of “agile” development and project management in general is a reduction in over-architected software solutions.  With project requirements being represented as stories and tools such as Kanban boards for lean software development to show the flow of work through a process, one might think the classic waterfall project management work and schedule reporting tool, the Gantt chart, is obsolete.  Before you abandon this tried and true project schedule reporting solution for the more transparent status inherent in agile project management, you may want to keep reading.

So, you have succeeded in transitioning your IT project management and delivery methodology to one that is more aligned with “agile” than “waterfall”.  Your non-IT stakeholders are more engaged than ever in the project requirements definition, prioritization and sprint/release scheduling process.  You are tempted to stop trying to use MS Project or other tools to represent schedules in Gantt form.  In a word: “don’t”.

One of the main criticisms of complete agile project management is: “The dangers are the loss of recognition that systems/solutions change continually over time as well as team members” Put in more direct, bullet point form from my experience of this criticism expressed by product or management stakeholders:

  • What is the big picture?
  • I have the big picture in mind, when am I going to get X?
  • At the current burn rate, how much time will be invested before I get Y?
  • If I add/subtract resources, what will be the impact on the big picture?

These are all criticism subsets that can be directly addressed with the data collection associated with producing a classic Gantt chart.  So don’t throw away those Gantt chart creation disciplines just yet.

What is the big picture?  I have the big picture in mind, when am I going to get X?

Let the sprint/release iterations continue, but don’t let too much time go by past the releases to meet with the product stakeholders and update your rendition of the product road-map.  (You have your road-map, right?  You aren't letting the business surprise you with all requests, right?)  This is a great opportunity to get an early indicator if product stakeholders have become caught up in their immediate needs and lost sight of the “cost” of those features.  By “cost” I mean the investment in features now means pushing out the product road map.  You can gently remind them how the “cost” appears graphically in a Gantt.  The Gantt view of their product can clearly show “milestone 45” getting pushed into the next quarter due to their recent feature bonanza.  It is much easier to have the “hey, I thought I was getting milestone 45 this quarter” discussion as soon as the schedule shows initial signs of slippage rather then at the start of the next quarter.

At the current burn rate, how much time will be invested before I get Y?  If I add/subtract resources, what will be the impact on the big picture?

Here again is where your mastery of tools such as MS Project  and the Gantt chart view of the product road map are exceedingly important.  If you are working for a MidWestern company, rather than say, a start-up, you can’t ignore traditional budget and resource management constraints.  As a start-up in growth mode, your focus is getting your product out the door with the resources you have or your resources plus the on boarding of additional resources.  In a MidWestern company, you are most likely trying to maximize the resources you have or being asked to reduce your head count while still meeting project expectations.  Thus, prioritizing features to be delivered against a shrinking resource pool is a given.  You need something beyond the agile sprints/releases under way to manage project stakeholder expectations on what can be accomplished when.

The Gantt view of the work allows for a graphical view of “if this is more important, what else is impacted” realities.  Additionally, add in the need to manage a fixed pool of resources across multiple agile projects and you absolutely have to have some way to represent a view of the prioritized work across all resources.  In addition, you may need additional tools to help represent the “what if our team member Sally gets assigned to the VP’s ‘special project’, what does that do to our resource model and what can get done when?”

Conclusion

As an IT manager or IT project lead in a MidWestern company that is moving towards more agile project management and technology delivery, you may be tempted to relax the project management disciplines that come with the more traditional waterfall approach, specifically tracking project schedules in a Gantt chart.  In order to avoid the inevitable product stakeholder expectation mismatches as well as pending budget cutbacks and/or uncontrollable resource re-allocations, keep collecting that “program management” data.  Continue to have re-occurring meetings to review the “big picture” Gantt chart view of the work and use other tools to reflect “what if” scenarios and their impact on the big picture.

Thursday
Jul152010

Scrum vs. Kanban: It’s like Football vs. Soccer

A few days ago a dude asked me to explain all the buzz that goes around with Scrum and Kanban, and mostly Scrum vs. Kanban. As my dude didn’t know much about Agile methodologies I tried a different approach.

You know dude, it’s like American football vs. European soccer.

Interesting, he replied, can you say more?

Of course, you know, actually they all say that they are playing football but when they refer to the other sport they call it either American football or European soccer. Both Scrum and Kanban are Agile-based methodologies, but it’s not the same thing. People believe that one derives from the other, but as American football it’s more like rugby and not soccer. And with Kanban it’s a kind of simplified and adapted Lean methodology rather than Scrum.

In American football, like in Scrum, time is heavily segregated into small time-boxes, giving the team a chance to re-organize and retrospect the previous sprint, as well as making strategic decisions for the next one (and of course making room for commercials which brings in a lot of money). In soccer, like in Kanban, time is more fluent, and only bottlenecks cause the game to stop. Sometimes, a small amount of time is added to to compensate the stops. A practice well spread among corporate Kanban practitioners.

In terms of commitment there is also an interesting parallel. Just watch an American football team in attack. The team briefly decides about the scheme and makes a small commitment (usually to advance 10 yards with the ball). The time starts and they face the unknown (the other team's defense). There are few intense moments when the team, synchronized, tries to play out their scheme. Everybody from the team participates at the same time: blockers protect the quarterback, running backs and wide receivers run around into positions as nobody from the defense team knows where the quarterback will pass. The team can succeed or fail with the attack. In the end there is always a collective succes or failure. Either way, the team regroups to learn from experience and to decide on the next attack. That’s Scrum dude, a well done Scrum.

On the other hand, in soccer, teams look to understand the unknown (the other team's defense) while they are playing. The main goal is to score, so keeping the ball in possession and good passes to each other are the key aspects of the game. Even though it looks like the whole team is participating in the attack phase there are passive players that wait for their moment. Passing the ball as fast and accurate as possible and actively looking to score sounds a lot like Kanban.

In my opinion, Scrum and American football require a lot more commitment and discipline than soccer and Kanban. That doesn’t mean that soccer or Kanban are disorganized, but they are a bit loose. Practiced well, by skilled and disciplined players, it gives a great show as you can see in the Champions League or World Cup. In fact, when played well both sports (or methodologies) bring satisfaction. But practicing it is another thing.

Gather about 20 sporty guys on a beach and try to put them to play soccer and/or American football. Quickly, you’ll see the difference. It comes more natural and simple to play soccer than American football. It requires less skill and less discipline, rules are a bit more simple and no extra equipment is required. Even more, if you further strip rules like no off-sides, or even no conners, the game is still fun and still makes sense. Also in Agile methodologies Kanban can look more natural and easy to adopt than Scrum, which can be more difficult. Software development teams can see Kanban as a more natural and easy approach. In the end it’s just a matter of perception as both Kanban and Scrum require both skill and discipline for a professional level.

By the end of the conversation my dude flees, so I decided to put this up as a blog post. Hope you enjoyed it! Comments are welcome!

Radu is the author of the blog The Backup.


 

Do you have an idea you want to share with others? Do you want to promote your blog with a guest post on this website? Check out the guidelines and submit your own article!

Tuesday
Jul132010

The Squeaky Wheel Gets the Grease = FAIL

In this article I shall explore the harm that happens to people on teams from this belief and suggest an alternative path that purges the squeaky wheel and reinforces the ones that work. What does "the squeaky wheel gets the grease" mean, in terms of people. The interpretation is that in order to be noticed, retain resources, move up in the company, to receive any recognition at all, a person must make noise and complain or squeak. This creates an opposite effect where those who are quiet, reserved, and believe that they will be noticed on their merit and hard work alone feel that they are not noticed, because they are not squeaking.

Click to read more ...

Thursday
Jul082010

The Great Migration

I was unhappy with the Ning platform that the Management 3.0 site had been running on for half a year. There were too many problems, too much spam, and this was topped with a huge change in their pricing model.

So I started looking for something new.

With a little help from NOOP.NL readers I found Squarespace.com. And it is great!

I am now busy migrating/creating content and designing/tweaking the layout. In one or two days all should be ready for the final switch!

Stay tuned...