Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

We Should Be Held Accountable

06.13.2014
| 6299 views |
  • submit to reddit

This article was originally written by Derek Huether.

Why We Should Be Held Accountable

When I speak to people (including Agile coaches) from other companies, I tend to see and hear a lot of interesting perspectives. Many buy into the idea of Agile being this cultural shift with everyone sitting around a campfire singing Kumbaya and feeling all happy. Personally, I think these people are getting the 10 principles of the Agile Manifesto confused with the 10 principles of Burning Man.  In reality, we’re all under a lot of pressure to deliver something.  People don’t pay LeadingAgile to just show up and do a magic trick. We dig in and get companies unstuck.  We have to work hard to keep teams and organizations moving in the right direction.  In order to help ensure delivery commitments are being met, I believe we should be held accountable. Empowerment without accountability becomes chaos…or at least a transformation that doesn’t really go anywhere.

Everyone is Organizationally Accountable

Employers hire people to do work.  Employees (including contractors, consultants, and coaches) have skills that contribute to something valuable that employers can sell at a profit.  When employers ask if we can get something done in a certain period of time, we can’t refuse to answer the question.  We can either say yes unconditionally, say yes but with an alternative timeline with justifications, or just say no.  Say yes, and we do everything in our power to make it a reality.  In our hearts, we want to keep our commitments.  We’re not doing ourselves any favors by making commitments we know we can’t keep.  I believe employers respect you more if you say you can’t meet a deadline and explain why, rather than keep saying yes.  If you are one of 10 or even 100 employees, and nobody can keep a commitment, I don’t see the business (or at least that employer) lasting for long.  We may not feel comfortable with the deadline. We may have to push ourselves.  But that’s ok!  People are going to be happy, if they are forced to make commitments and then they actually get it done.  Why not leverage Agile practices to help keep commitments?  Don’t get confused. The goal is not to be Agile.  The goal is to get stuff done by focusing attention on the right stuff at the right time, always keeping your eyes and ears focused on what is most important to the business (not you).

I am Personally Accountable

As an Agile Coach, I hold myself personally accountable to a client.  We write a statement of work.  I commit to do certain things on a certain timeline.  I should not accept an assignment if I are unwilling to commit to the deliverables or timelines.  Sound familiar?  As an Agile Coach, would I ever ask a Scrum team to do less?  Sometimes, as coaches, we become myopic.  Coaches should understand the engagement from a high level (epic), what timelines or deliverables are valuable to the client (features), and chunk those down into manageable and measurable pieces (stories) that can be demonstrated to the customer on a regular basis. As an Agile Coach, I should be able to use the same metrics I use with client teams.  What’s my completion ratio (am I meeting the commitments I recently made)?  How long is it taking me to deliver something of value?  If the engagement is for a few months, I should know the high level goals. If for just a few weeks, I should have a known list of deliverables with articulated acceptance criteria.  Every day, I should be prepared to tell the customer what value I will deliver today and what value I delivered yesterday. Empowerment without accountability becomes chaos. Do you agree?  Should we all be more accountable?

The post We Should Be Held Accountable appeared first on LeadingAgile.

Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Martyr Two replied on Fri, 2014/06/13 - 5:59pm

That is all good and well and I commend you on your discipline to holding yourself accountable. I can tell you that the company I work for has a really tough time with this right now. Everyone commits, no one delivers on those commitments and yes, the company is hemorrhaging cash. But what are you doing about the situations where you make a commitment, they change the game on you making you do more for the same timeline? Oh sure you have a statement of work that you are then forced to redo but they don't have time or the want to again renegotiate. All the meanwhile it looks like you are the inflexible one.

I think many programmers can relate to this. You are brought into a room by management, you are told what they want to do, you are then asked how long it would take and asked for a quote before you even can see all the pieces of the project. You ask for some time to research, but then they throw out the "Well just give us a ballpark" line. You give them something padded out, but still a wild guess and even though you just told them it was a guess, they schedule based on it and hold you to account for that timeline... again before you even know all the pieces.

Then of course your time runs over and they are asking why you are not done yet. I have yet to figure out the magic solution to this problem that I am sure many people who read this will have experienced. The best solution is to never commit to a date until AFTER you have gone and done some research... because in the end three things will happen. 1) You will see them bring in some new requirement as soon as you step out of the meeting and 2) You will realize they inadvertently "forgot to tell you something" and 3) The timeline they want you to commit to has no bearing on their timelines. Sure you were done in one week but the committed to someone else 3 weeks.

But good points you have there... in an ideal world I wish that is how it was.

Dimitris Menounos replied on Mon, 2014/06/16 - 3:57am

@Martyr Two

So True!

Doug Shelton replied on Wed, 2014/06/18 - 10:26pm

Mike:

Of course you are right - "ground-floor" development staff are **Not** hired to "Be Agile", but to "Produce Product".

I think the reason you see so much blogging (to the point of  "word salads") on the topic of the importance of achieving an agile culture is because of the strong belief that if this is indeed achieved, you will in turn advance to hyper-producing teams and be able to "deliver product" **better** - i.e., in fact BE more productive.  One , ah, shall we say, Less-successful "pattern"" you may often observe particularly in "bigger" companies is the creation of "spots of agile" - which often have much less chance of success [in achieving those hyperproductive teams] than "overall agile across the entire Dev organization and with full participation of business" in getting to this productivity.  This in turn happens because is quite difficult to get to "overall agile" without having to change that organizational culture.  The classic example of why this is the case is the siloed organizational structure with some silo managers not understanding or committing to the "strong matrix" needed for contributing members of their particular functional groups to the agile teams

Also - for New agile implementations - quickly getting that "agile mindset" firmly understood and supported in the minds of middle and senior management is critical, because - really like **any** major process change - changing existing development processes to Scrum, et al will upset the applecart "for a little while" and there will likely be some setbacks and failures as teams adjust.  This isn't an agile "Failing"  per se but more or less a normal side-effect of massive & far-reaching process Change.

Finally - statistics produced and tracked by some major agile thought leaders (like Mike Cohn) as well as some major Agile PMS companies (e.g., Rally) show that:

(1) There is a strong bias toward actually over-committing on the part of Developers.  The empirical nature of averaging out velocity should be used to address this to set realistic expectations; 

(2) There is **quite** a lot of variability of "points achieved" from one Sprint to another - so again, part of appropriate expectation setting - not only for the release but from one Sprint to another - should be to measure that variability and communicate it accordingly to the business.  Teams shouldn't necessarily be "penalized because the average velocity over their first three Sprints was say, 9 points, but in their fifth Sprint, it was say, 6 points [even if they were now shooting for that "average" 9 points in this fifth Sprint] - all the more so if that range of variability has previously been measured and found to be the case.  Of course, I do agree the retrospective should be used to "find out why" this happened, but it may simply be a case of underestimating the effort - for any range of potentially acceptable reasons.

But YES - - ultimately the end goal **is** increasing productivity - which I've personally see can raise resentment on the part of team members who already think they **are** being productive - often because they are working far more than the "standard" 40-hr workweek already (and on top of that, don't have anywhere near a full awareness of the advantages in "shortening product cycles" that agile can provide as well as avoiding the many kinds of waterfall-type overhead "waste").

So - To Summarize: I agree the focus needs to be on producing product [along with commitment of ground floor teams to doing so] and agile culture should never be an excuse **Not** to do this.  However, that doesn't mean achieving an agile culture is **not** valuable - I trust my arguments above have made the point to the contrary.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.