Any questions?
I went to my first Agile Conference! I guess I’m always a bit uneasy when I’m surrounded by people who more or less think the same way I do. On the other hand, it feels great! It’s a stark contrast from what I’m used to – you know, being surrounded by Architects, DBAs, PMOs and project managers who a waiting in the wings to save the day when this “Scrum thing” fails.
So for five days, I dove in the pleasant warmth of my fellow agilists and shared ideas, laughs and a few drinks. Attending the wide variety of sessions was my preferred activity and a great opportunity to listen, participate and learn.
Enough chit chat, let’s get right into it…
My first session was “Leader’s Workshop: Making Change Happen and Making it Stick” with Mary Poppendieck. I won’t go into details so here are a few points…
Mary states that to encourage change, one needs to provide:
1- The proper kind of motivation
2- A clear direction
3- A supportive environment
So what motivates people?
Mary references books such as Switch, Drive and that great video by RSAnimate
A very interesting point is to manage employees as if they were volunteers. With money being out of the equation, what needs to put in place and maintained to keep motivation at a high level? What keeps a volunteer motivated?
- A clear purpose
- Structure and guidance
- Successful project
- Ownership
- Autonomy
- Bragging rights
- Mastery
- Constructive dissonance
What I take back from this session
You can throw all the cash you want at your problems and they still won’t go away. If you want successful projects, hire smart people, offer them a clear direction, a few rules, and get out of their way. Smart people will find a way to make it work.
As agile coaches helping organizations transition to a different way of doing things, are we doing a disservice to our clients by accepting a mandate that we know deep down will most certainly fail? Are we failing to recognize the fact that any attempt for a particular client to adopt an agile approach to software development is simply too far out of their reach?
A not so far-fetched example
Let’s just imagine that we walk into DoMoreTech Inc. and we are confronted with 40 developers, 4 QAs, a few ivory tower architects and control hungry project managers. Not to mention a management team that believes taylorism is still the best way to create software.
The Java developers are totally separated from the back-end C developers. A test means starting up the Tomcat server and clicking away. If you mention unit or automated tests, they look at you like a bunch of deers caught in the headlights. For the past 20 years or so, C developers have been masters of their domain and are very comfortable working within the three and half carpeted walls of their cubicles. One of them even installed a makeshift cardboard roof to cut down on noise! Oh, yes! And everyone is working on at least 5 projects in parallel.
The QAs are on a mission: Embarrassing the developers during the weekly “team” meeting. To ensure that they reach their bug finding quotas, they withhold information that might help developers today.
Developers tremble when he appears at the elevator doors. Even the paying client with clearly define business needs folds under the pressure of the all mighty Architect. The Architect has positioned BDUF as a critical process that must be respected for any and all projects to be successful. This well defined process is flawless and the Architect’s design is always perfect and final. If there’s a problem, it’s obviously due to the developer’s lack of maturity and experience.
Project managers and management are really happy that this “Agile thing” will help them do more with less. Since they are not part of the problem, only the technical teams need to improve the way they work. Now that they have “purchased” Scrum, they have ADDITIONAL tracking tools to better control the situation and make better decisions for the teams.
Ok. Now what?
After a few days, when all these non-winning conditions are confirmed – What do you do as an Agile Coach? Jump in and hope for the best? Run away and never look back? Or maybe do away with the detailed diagnostic and simply leave a Hallmark card on the manager’s desk saying: “Sorry, but this ain’t gonna work”
Personally, I’ve seen watered down variations of the example above in different organizations and I’ve never turned down a client. But to even hope for agile transition to succeed, the client does need to comply with two simple requirements:
Requirement 1
A pilot project (unless “Big Bang” implementation is considered). Neither a small and meaningless “test tube” project nor a do or die project. How about something just in the middle that involves external dependencies and creates value?
Requirement 2
We need a team. To quote a colleague of ours: “We don’t coach projects, we coach teams!” And this team needs to be committed to one project. This Scrum team will be composed of a ScrumMaster, Product Owner and qualified individuals to create the solution.
Whether or not these requirements are met, a Mandate Charter is created in collaboration with the client to clearly define, among other things, the conditions of success (COS) of our initiative. Taking time with the client to establish the conditions of success is a great collaborative activity and allows us to have those hard conversations and setting some facts straight.
If the basic requirements are met, the COS can be far reaching and beautiful things can happen! If not, the COS might be superficial or even cosmetic in nature. At this point, decisions need to be made. Is the client willing to pay for cosmetic changes to his or her organization? Does the client see value in these changes and is he or she able to sell ME on it?
It’s all about managing expectations. A client can’t expect an agile coach to turn water in wine. But allow a coach to work with some quality basic ingredients and we just might end up with an award winning Cabernet Sauvignon.
Party on!
In December 09, a colleague of ours was a tad bit envious of a great initiative leaded by Laurent Cobos. Laurent, through a collaborative effort with the Pyxis developer community created the Pyxis Developer’s Charter.
Seeing the rallying effect of the Developer’s Charter, we attempted to launch a similar initiative for Agile Coaches, but we had limited success. Coaches being in high demand these days, we had less time to invest in developing a strong and honest charter that other coaches could easily identify to.
We did however identify some conditions of success:
- The language must be business compatible
- Must show that the coach is accountable to the client
- Must show that our client is equally accountable to the coach
- Can included specific practices
- What else?
And through our internal wiki and a couple of meetings, we came up with this:
As an Agile Coach, I commit to the team and its organization to…
- Never apply recipes
- Respect your distinct culture
- Help you challenge your current culture, principles and practices
- Let you learn from your mistakes
- Not let you make irrecoverable mistakes
- Put in place an empirical process that allows learning
- Allow you to evolve within that empirical process
- Allow the process itself to evolve
- Have to courage to say No
- Guaranty bug free software
- Telling you what you must hear and not what you would like to hear.
- Not inflict help
- Help you expose the value you create
- Help you expose non-valuable activities
- Help you identify obstacles
- Help you identify solutions
- Help you to communicate efficiently
- Be continuously aware that I can be profoundly influenced by the non-Agile surroundings, immediate context and personalities. (Inspired from The Tipping Point)
- Stay true to the Agile Manifesto
What would you add, change or simply remove?
What makes uncomfortable?
Which statement makes you stand-up and cheer?!
What would be your preferred format?
Would you sign this Charter?
Warning: The following post might provoke a mild aneurism to some scrum purists.
Don’t you love a nice, clean and deep Product Backlog, filled only with strong user stories tightly linked to clear business objectives and estimated by business value and story points? As an Agile coach working with large organization with even larger challenges, I don’t usually have that luxury. And If I do, I don’t believe it! The amount of stuff that needs to be done to ship out quality software is astronomical and never ceases to amaze me. So of course the “Definition of DONE” is equally immense.
The definition of DONE
Creating and shipping software in large organizations involves tasks and deliverables that go beyond straightforward testing, coding and releasing. To get all this work out into the open, I ask teams to focus on a couple of “juicy” user stories and ask them to identify ALL that needs to be completed to get this product in front of the user. We might get something like this:
And the list goes on and on…
Teams are then challenged to get everything done within a user story. Of course this is impossible. The best the team (and the supporting organization) can do for now is to complete some DONE items at the sprint, milestone, release or project level (see fig.1)
Figure 1
The further away we are from the user story level, the more nervous I get. At the beginning of an Agile transition, I can live with that as long as we identify these “non-story DONEs” as debt and we manage it appropriately. I don’t judge or question any of the DONE items (ok, maybe I do, but not out loud) But I do want to the team and the organization to clearly see the sheer volume of overhead and offer them some kind of tool to start cutting out the fat.
This tool will be…The Product Backlog.
The team will manage this debt by adding non-functional work items in the Product Backlog. In other words, all DONE items not included within a user story will become a work item in the Backlog. If the team’s initial estimate is 4 sprints for a release, then those sprint-level DONE items will appear four times. This continues with milestone, release and project DONE items. This makes for one polluted Backlog – And that’s ok…For now! As you can imagine, this can double the scope of the project.
A product backlog can go from this:
To this:
What does it mean?
Based on the team’s velocity, it’ll probably take 4 to 5 sprints complete the project and not 2 – That is, if nothing changes. It means that it won’t take 15 points to produce $26,000 in business value but at least 33. Nasty!
It can also show an organization that went through a chaotic period and decided to structure all that is I.T. into a defined process; a normal reaction. Over design and over documentation is heavy and expensive, but it’s still better than the anarchy of the early years.
Finally, it means we need find the correct balance for this project and organization.
What do we do?
If the organization is polluted, so shall be the Product Backlog – Deal with it! No really, you need to deal with it.
The Product Backlog can’t remain in that state. It’s needs to be filled, almost exclusively, with items that deliver business value. That said, don’t hide the real work that currently needs to be done or simply take that work into consideration by inflating story points. It needs to be out there, for all to see. We want to provoke a sense of urgency and change.
All the $0 business value items are now action items, things that a Scrum team and the surrounding organization need to deal with now. If we can’t eliminate an item all together (Ex.: Code document? – I mean come on!), then we need to find out how we can reduce the effort needed to get it done. We need to reduce waste and those dollars signs might motivate those upper management folks to get things moving.
This approach is provocative but in many large organizations, shock and awe is often required to encourage change. If a Product Owner and ScrumMaster can clearly show that it costs $1 to create $0.25 of value, I promise you that something will happen.
So between a polluted Product Backlog and a clean one that doesn’t show us the full picture, I choose the former…For now!
It’s almost T-minus zero for the 2010 Agile Coach Camp! This open space forum for Agile coaches will be held on June 11th and 12th in Waterloo Canada and will be a great opportunity to see how our profession is evolving and practiced in the field.
Being in an open space format (which I love) we’ll all have the opportunity to expose our own views and experiences and of course learn from fellow practitioners. Looking at all the position papers, I don’t think we’ll run out of topics!
That said, are there any Agile coaching subjects YOU feel passionate about and consider important to bring up during this event? If so, feel free to propose it and it’ll be my pleasure to add it to the queue!
I’m looking forward to sharing my experience in my next post!
Like most of you, I’ve had my fair (or unfair) share of meetings. Some were great and a lot of them were just ok. But a few weeks ago a colleague of mine said something during a ROTI evaluation that forced me to look back at all those previous “great” meetings and re-evaluate their TRUE value.
What he said was: “Am I my really obtaining value from this activity or am I just having a good time?”
My jaw dropped!
How can such a simple statement stir up so many issues in my mind? It not only forced me to re-evaluate the specific activity he was referring to, but everything else I’d done and was about to do!
Leaving aside the fact that fun has value in itself, why not challenge an initial assessment with a Fun vs. Value Evaluation? A meeting might have been fun, but did we reach our objectives? As an Agile coach (or ScrumMaster), if I suspect a misinterpretation of the true value of a meeting or an activity, I might try to validate it by whipping out a Fun/Value graph:
No fun and No value
If the meeting had low value, there’s a good chance that fun is also on the low side. Those situations are usually easy to detect and numerous corrective actions can be put in place.
No Fun and High Value
Now here’s an interesting situation! We managed to reach our objectives but getting there was about as much fun as a root canal. This situation might hurt in the long run as valuable contributors conveniently forget to attend.
A Scrum example:
The recurrent Product Backlog estimation meeting (Backlog maintenance) is essential and the team is able to reach its goal with a two-hour meeting…but for most it feels like a five-hour meeting. The team sits in a large conference room, the projector is humming and item by item, one or two members shoot out some “man days”.
Why not estimate using Poker or Wall planning? Maybe every two weeks, we hold this meeting in a local café or bar. Everyone contributes, estimates increase in value and…IT’LL BE FUN! We might even save time, making it still more fun!
Lots of Fun and High Value
This is good situation to be in! Some might say, if it ain’t broke, don’t fix it. I’m more of a “Good is the enemy of great” kind of guy. But trying to make it even better can be tricky. If such attempts are made, make sure the team buys in to it or better yet, get the team to come up with new and innovative ways to reach their objectives more efficiently.
Lots of Fun but No Value
Now here’s the situation that motivated me to write this blog. Is it possible to be blinded by fun? Of course! The meeting might have been called to shed some light on a problematic issue, but ended being little more than a laugh-fest. We walk out of there feeling pretty good but the real issue is nowhere near being resolved.
Where I work, we have bi-monthly meetings to explore various situations when coaching individuals. We do this through role playing; two individuals acting as coach and coached. As you can imagine, some scenarios are quite hilarious. Fun and laughter is guaranteed! It was so much fun that I had a (false) sense that we were accomplishing something of substance – that is, until my colleague casually questioned himself and stated, “Am I my really obtaining value, or am I just having a good time?”
Once I filtered out the laughing and that great feeling associated with being with my colleagues, nothing much was left. There was some value but not nearly as much as I initially thought. It looked something like this:
With that new information in hand, we restructured the activity in order to increase its value, all while maintaining The “Fun”.
Value or Just Fun?
It pays to be aware of what zone we are in, especially when in the “Misinterpretation Zone”. High levels of fun are beneficial to any activity, but reaching clear objectives remains the ultimate goal.
I’m looking forward to applying this in the real world and seeing what happens! I’ll let you know how it goes. 
Situation :
You have one project with 100 developers organized in Scrum of Scrum.
Question :
Do you go with one Product Backlog or multiple Product Backlogs or something in between?
- No one knows who the Product owner is
- Tasks in Sprint Backlog are dictated by the Product Owner
- The team’s default behaviour is to assume what the Product Owner wants
- The Product Owner doesn’t understand that great new feature presented during the Sprint Review
- All features presented during the Sprint Review are refused by the Product Owner
- Items in the Product Backlog are estimated and prioritized by an architect
- A Blackberry is the Product Owner’s main tool during a Retrospective
- The Product Owner’s main argument during a Sprint Planning is: I don’t care. It has to fit!
- The team’s response is: Ok, we’ll make it fit! (Squirrel Burger)
- Sprint Planning, Sprint Reviews and Retrospective are all perceived as overhead!
The ScrumMaster is one busy bee! If the team is less than fully self-organized, her plate can be quite full. If the organization is less than Agile, there isn’t a “Certified ScrumMaster shovel” big enough to handle all the issues that arise.
Every day, she tries to improve the development team’s engineering practices, productivity and generally make their lives better by removing barriers and shield them from external interferences The ScrumMaster also works closely with the Product Owner by encouraging him to communicate directly and frequently with the development team and teaching him to maximize ROI and meet his objectives through Scrum. And that’s just the tip of the iceberg!
But something else doesn’t feel quite right. How are we planning to sell this “best thing since sliced bread”? Our ScrumMaster is highly skilled in group dynamics and most Agile engineering practices, but couldn’t tell the difference between a marketing plan and a Snickerdoodle cookie recipe. But she does know (as does everyone else) that for the project to continue, we need to get those product licenses out the door! What can she do?
The short answer would be: The same as with all the rest!
What would a ScrumMaster do if she knew that “technical excellence” was not up to par but knew little about Test Driven Development (TDD)? In order to insure that this Agile principle is applied, I figure she’d identify a TDD champion within the team or get some outside help and encourage coaching and pairing. She would also expect the team to continuously improve their engineering practices and allow the product to evolve easily and maintain its high quality.
Why not apply the same approach in regards to the marketing plan? A ScrumMaster could once again fall back on the sound principles of the Agile Manifesto and use them as a guide. Below are a few of those principles that could add great value to a marketing plan:
A marketing plan should welcome changing requirements
Marketing requirements can be as volatile and unpredictable as software requirements. Despite the initial overall marketing strategy, our Product Owner must lead the initiatives to adapt the plan based on the availability of new information, such as competitor strategies, market trends and of course, the evolution of the product itself.
Business people and developers must work together
Don’t allow a third party marketing firm work in isolation with the Product Owner. As a ScrumMaster, make sure you get the developers involved. These professionals are building the product! Who better to offer input on how to sell it?
We should test the plan and see if it’s “working”
How do we test a marketing plan? Maybe after a couple of Sprints, could we execute a subset of the plan, get some feedback (or lack thereof) and adjust the Product Backlog accordingly?
What other Agile principle could apply?
Recent Comments