« Managing Projects on a Global Scale
The Insanity of It All! »

The Management of Management in the New Agile Organization

January 29, 2011 | Author: PM Hut | Filed under: Agile Project Management

The Management of Management in the New Agile Organization
By Cindy Vandersleen

All too often I hear about organizations that declare “We are now Agile…” or someone in management looks at the development team and says: “go forth and be Agile…”, and then throws them to the wolves to figure out how without any training. Some in the leadership may embrace it enthusiastically and say “we need to be more agile…”, while others are complete skeptics and believe that without all the usual documentation, no work of any quality could possibly be getting done. Indeed one of the biggest challenges in trying something new like agile practices in an organization is managing expectations of the leadership.

For many leaders who don’t really understand what agile is, they believe being agile just means they’ll get stuff done faster. They don’t understand or care about any of the methodology or process changes required to make it work. They’re thrilled with the prospect of getting work done faster, but they still want that MS Project Gantt chart, status reports, budget reports, and a complete signed off scope statement. Oh, and when they have an emergency fire drill, they want the ability to halt your project and divert your resources to go work on their pet initiative – but you still need to get stuff done faster, because you’re agile now right? Early education and communication is the key to easing your way through these potential bumps in the road.

Below are some of the key friction points that are best to educate your management on with regard to agile methodology sooner than later:

  • The first iteration will almost always be a bust. The team is learning how to estimate their work an entirely new way with relative story points, and assessing how much work can be fit into a preset allotment of time. It is very typical for the team to overshoot and not get all the work done that they carve out for themselves. It usually takes 1 or 2 iterations for the team to gauge their velocity or number of story points they can accomplish in an iteration. Only then should an attempt be made to do any type of release planning so you will know how many iterations it will take to achieve all the functionality desired in the release.

  • One of the benefits of agile is the flexibility is offers around scope change between iterations, but the cardinal rule is that once the scope of the iteration or sprint is set, no one disrupts the team. That means no high level stakeholders pulling rank and diverting team members to go work on another project. This is one of the reasons the iterations are kept short – no more than 30 days usually, and sometimes shorter, so that the team comes up for air frequently to entertain changes. An obvious issue with this design is the case where the same team must support bug fixes as well as new feature development. One solution to this is to build into every iteration some buffer stories for unknown bug fixes that can be assigned if critical bugs are logged during the iteration that must be addressed by one of the team members.

  • On an agile team there is no traditional command and control model. There is no traditional project manager role. The scrum master has no direct authority; he/she is more a facilitator. The team is self directed and self organizing. The team members assign themselves work from the waiting tasks list. This is a hard one for many managers to swallow. They believe that without a supervisor to crack the whip, the team members will have no motivation to work. Most scrum masters find the opposite is actually true. If anything, they have to coach the team to be less aggressive and not bite off more than they can chew. When held accountable for their own work team members will most often rise to the occasion and try harder to prove their worth and value. Where scrum masters do add value is to coach team members to direct their effort towards completeness of fewer stories rather than near completeness of more stories. The only stories that can be demoed at the end of an iteration are completed stories.

  • Agile means fewer artifacts. There is a product backlog containing user stories, iteration backlog, and some burn down charts. Typically that’s it. If there is anything more, it is due to organizational culture requirements. As the engineering progresses and conversation happens between developer and business, validation requirements (which is where typical detailed business specifications would be captured) will be developed and captured as part of the test driven development process – which is where it should be to have any real utility. How often have you really ever looked at those extensive business requirement documents (BRDs) after they’ve been developed? Certainly by the time a new project is launched, they are usually outdated and if they are even archived anywhere, they are usually never looked at again. All that effort wasted. So spending the effort getting the right people talking in the first place and documenting where it needs to be won’t result in a lack of valuable documentation, because all those BRDs were never truly valued much in the first place.

Spend time making sure your management really understands how the new agile team will work with each other and with others in the organization and what is expected of them before you start. They will appreciate the education and it just might keep you from becoming the next Dilbert cartoon.

Cindy Vandersleen is a certified project management professional and has held positions as an executive IT leader with progressive experience in information technology and project management disciplines. She is an approachable business partner and compelling team leader, guiding teams to successful outcomes through problematic environments. Cindy led teams successfully through several mergers, acquisitions, and offshore outsourcing initiatives. Cindy can be contacted through her website, The Project Coach.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Saturday, January 29th, 2011 and is filed under Agile Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories