Managing Expectations - Better Agile Managers

The question I have been faced most with in a recent engagement was, "How do I manage expectations when so many people are asking for different forms of the same deliverable? How can I expect my team to keep that many balls in the air?"

My reaction, after the shock settled in of course was, what is so out of the ordinary about the expectations that have been set for you and your team? Furthermore, what did you do to retain upward visibility while still maintaining distance between management and the team?

A recent Leading Agile Post reviewed the role of a manager on the Agile team and even went as far as decrying the demise of the role of manager on many teams while trumpeting the fact that managers will never go away. The final verdict sounded like something I have been saying for some time. After numerous comments and a long twitter thread, all agreed that the role of an Agile Manager needs to evolve. This beckons the question, how do we prepare managers to be recipients of Agile projects and how do we establish reasonable expectations for the team that they may agree to?

The fact is, managers got to the position where they currently work due to their ability to make great decisions and to assist as many others as possible to reach project completion. When the rubber hits the road, these are the people who are recognized for their ability to get things done! I truly feel that the most often overlooked piece of the puzzle is the re-defined role of the manager as a servant leader.

I just do not believe the hype about any team who claims to be 100% self organized. At best I have seen teams 10% self organized in a pool of 90% comand and chaos! As more and more teams embrace Agile and Lean thinking, teams will need to rely more on solid managers who have redefined their role to fit in the agile schema and will progress by having servant leadership available to remove obstacles when necessary.

The last remaining thought is how do we get ScrumMasters, Project Leads, Program Managers, Development Leads & Mangers, Product Managers & Owners, Etc. to better understand their new responsibilities on the newly rock solid Agile or Lean team? My guess is that this will require a little more doing than reading, a little more positive re-investment as opposed to scrapping the role alltogether.

What we really need is a defined Agile Mentor. We all know the first step is to understand all of the pieces of the puzzle. The next step is to seperate the edges from the middle pieces. Next we match like colors, and finally we work as a team to build a high quality puzzle. Why should we treat this any different? We really need to stop for a moment, take a deep breath, regain our focus, and scream to the world that we can be Agile! We can follow Lean principles. We are ready to do what it takes to be successful.

Get Something Done...Be Agile

How many times has the team decided they would start on every item without getting any items done? One comon Agile myth is that it is ok to start on every task just as long as you get them all done by the end of the iteration. We all know what most comonly happens is that the team underestimates the amount of time it actually takes to get work done, and end up not finishing anything they started.


I am starting to become a believer in the Lean WIP concept! It just seems logical to me that with a WIP limit in place, fewer things move to in progress and more work gets done. This means fewer items get left started and not completed. This means happier product owners and project managers.


The picture that came to my mind as I thought of this was Thanksgiving dinner. What if I started cooking everything all at the same time, but did not agree to finish cooking anything. Then as people became more hungry, I agreed to complete various items at various times. I just could not imagine that the guests for dinner would be pleased with such a concept.


Teams need to get used to the concept that they are not at work to punch the timeclock, nor will they receive recognition for How much work they got underway! Our effectiveness is based on the amount of work that gets completed. One of our goals should be to never leave the turkey half baked! We all need to get in the habit of doing as we say and saying what we will do. We need to do a better job of continuous flow of information and maintaining the highest levels of visibility.


Institute best practices, be Lean, be Agile, enjoy Life!

The Cost of A Bug..

One of the things that attracted me to Agile development is the focus on customer satisfaction. There are generally three things that customers hate the most: late delivery, cost, and bugs. While each of these obstacles have their own dynamics, they are interrelated. For example, late delivery usually means it costs more and fixing bugs generally means more time and money.

Over the last several years managers, directors, and executives have asked me to present empirical evidence that Agile will cost them less money and take less time. This is a topic that can be discussed for months on end resulting only in opinions or experiences, but no empirical evidence. To add to the complexity, in the software industry there are many variables that can influence the success or failure of a project and it's not very likely that every organization is in the same situation.

How can bugs, cost, and timesavings be measured on a new project and do they mean the same thing across different organizations? All of the organizations I have worked at that do Agile have decided to do so because of the hype or because someone read a book about it. In other words, in my experience, organizations seem to take the leap based mostly on faith. However, there are organizations out there that insist on hard-facts.

A recent paper (http://www.springerlink.com/content/q91566748q234325/?p=7fd98b01480f49e2925f36393c999a72&pi=3) published by Microsoft and IBM, showed that practicing TDD versus general unit testing reduced bug density by 40-90%. Reading this paper gave me one data point; bugs are one of the three things listed above that customers hate the most. The question is can bugs be equated to time and money?

The good news is that I went through an exercise with a director and several managers a few months back. Now I have managers knocking down my door for TDD support. More information can be found on this topic in the August Agile Mentor Newsletter!

- Christian Hargraves (AgileDad Feature Writer)

Christian has been an Agile activist since 2001. He presented at Agile 2007, Agile 2008, AgileRoots and to several smaller audiences. Christian has been a consultant and an active mentor in Agile, TDD, general unit testing and automated testing for the past several years.

Empowering Agile Teams - Agile Roots Presentation!

Time for a little brain exercise.. I have delivered this Empowering Agile Teams presentation a number of times, but never in this short of a timebox! I almost liked it better shorter. It kept the delivery crisp and kept the audience engaged.

This is a presentation that in my opinion needs to be delivered to EVERY team and leader on an Agile project! The message is that we are all accountable for the success or failure of an Agile project. The delivery is a bit unconventional but the message is VERY clear.

Take a moment to review the video:

http://agileroots2009.confreaks.com/15-jun-2009-13-45-empowering-agile-teams-lee-henson.html

and let me know what you think. Feedback is VERY much appreciated! ConFreaks did an AMAZING job with the audio/video for this conference! Slide deck and notes are now available in the section on the right. Thanks for taking the time to review and leave feedback!

The Price of Freedom

How do we measure our freedom? How much does it really cost to make decisions that help us remain free? What steps do we take to endorse continued freedom and what do we sacrifice to make freedom available to everyone?

To some this may sound like pure patriotic banter, rest assured, there is a much deeper message. For some time, I have been advocating empowering Agile teams and allowing them the freedom to make choices that impact the progress on the project they are working on.

I have also at great length discussed the level of accountability that comes with the power to make decisions. After a period of deep retrospection, I have come to realize that for every organization, there is a price to be paid for freedom.

For most, the price is small in the sense that minor adjustments help the team stay focused and on course. For others however, this is not the case. People harness their new found power and create a negative environment where the work takes sidebar to personal and team agendas. This in turn negates the value Agile provides and taints the pool of hope for Agile to succeed.

In order to best take into account the one loose wing nut or rouge team within your organization, it is vital that some organization take place that sets a clear and solid mission with directive that establishes a goal with clear boundaries. Many people may feel like I am discussing Utopia here, I would argue that I am discussing practicality. It is OK to empower the team as long as the outer walls of the room still remain in place. It is more than OK to empower team members to make decisions that allow them to contribute at a higher level. It is not OK for team members to take this power for granted and create a price tag for hijacking Agile. (I wonder if that URL is already taken? http://www.highjackagile.com/?)

At this time of great economic recovery, we need to "let the product lead, make everything visible, and inspect & adapt often". Doing so, will allow for the price of freedom to remain low and afford organizations with Agile Implementations continued success. Now is the right time! Wave your Agile Flag! Consult your product council. Build tangible memories for years to come!

Command & Chaos

Ever had one of those days where you just feel like you are reeling through the planning only to discover that once the plan is in place it is not exactly what you had hoped it would be?

As a result you decide the plan was poorly constructed and decide to plan again, only to find that by the third attempt that you may never get the plan just right. I am of the belief that a poorly designed plan that is executed actually gets the team farther than a perfectly designed plan that is never executed.

At the most recent Agile Roundtable we referred to this phenomenon as Command & Chaos. All too often we try to force the square peg through the round hole or try to perfect the square peg just so it will fit. A better approach would be to initiate contact with the square peg team and build a peg that works. A peg that can still be sanded, stained, and polished to look and work just as well if not better than the peg you started with. I have learned through experiences with my family that most often the poorly planned days turn out to be the most enjoyable. This is not to say that some planning is not important as a day at the pool in mid-January may not be as enjoyable as on a warm summer day.

When all is said and done, we should plan just enough to be responsible and execute as often as possible. Command & Chaos does not work and is certainly not going to solve your problems. Just ask Joe CEO (pictured above), and he will tell you that the Agile plan is in place to let him know sooner whether things are going smoothly or may not turn out as planned. The last thing we want to do is catch this guy by surprise. Be responsible, be accountable, be agile.