Why are we doing Agile?

We just had Southern Fried Agile in Charlotte.  See SouthernFriedAgile.com

I have 5 take-aways.  For today, the first one.

1. Why are we doing this?

We are not doing Agile for Agile's sake. We are doing it because we think it will help.

And the most important people to help are.... well, first, everyone.  Everyone at the same time.  Unbelievable.  But that is too broad for most of us.

First, the customers.

Secondly, the widows and orphans that own the firm (and, ultimately, it is the widows and orphans who own the firm).

Third, the workers and the managers (although in knowledge work, where you separate worker from manager is hard to see...).

Making people's lives better is often overly abstracted into the notion of delivering Business Value.  And that is mostly correct.  But remember that we are delivering business value to real people.  We are real people, and even they (the customers) are real people.

So, we talk about how lean-agile-scrum is so important, and it is, but only as a means to helping the lives of real people get better.

***

Change is always hard.  They say birth is painful.

If it is 'too hard' to become truly agile in X period of time, should we compromise?  Is it better to compromise?

The logic being: the benefits of X (agile, for us) are not worth the pain of the transition.

(Fortunately for human life, most women do not find this argument compelling enough.  Although you see in the eyes of 'new' mothers some thoughts like this. Before the baby is really real.)

Umm.  Very difficult question this is.  Worry about it you will.  Act you must.

And if we compromise (of course we humans always do), should we become complacent with what we changed to 'in the first jump'?   NO!!!!!

***

One of the key points...   We agile people too quickly assume that others (eg, executives) naturally understand why agile is important, and 'care' about agile.

And, one point is, they often do not.  They care about people, they care about business goals.  But, they do not see the necessary connection between business goals and agile.

We must always remember this.

Even with people who understood agile a month or two ago, we always should remind them, and show them well, how agile gives them the benefits they need and want.  Agile is a means, not an end in itself.  Let us not conflate the two.

***

Do I still think that, in most situations, by doing less Scrum-Butt people will get more benefits.  Yes, strongly!!

Do I think that everyone everywhere must immediately do, and only do, pure Scrum?    Well, I think that is too broad or aggressive a statement and not worth answering. For example, I will never talk to or even see 'everyone'.

 

Impediments - Charlotte - Oct 2014

This the list that this class identified:

1. Indecisive
2. Little stakeholder engagement
3. Started development late
4. LOB changed strategic direction
5. Assumptions
6. Lack of Test Environment & Data
7. Undefined risk
8. Lack of communication
9. Missing requirements
10. Too many bugs
11. No DOD
12. Time constraints (this is not yet a actionable impediments...but an issue for analysis IMO)
13. Backing into dates
14. Unreasonable deadlines
15. Poor leadership
16. Politics
17. Loss of team members
18. Opaque decision-making
19. No standards and practices
20. Third parties
21. No team - everyone for themselves
22. Change
23. Scope creep
24. No mitigation strategy
25. Poorly defined success criteria
26. Bad or no acceptance criteria
27. No business face time
28. Uncooperative team members
29. Laziness*
30. Lack of clear communication
31. Poor documentation
32. Difference in down time
33. Additional server & DBAs (lack of)
34. Product delivered on time with fewer defects (lack of)
35. Cloning test envronment
36. Team location distributed
37. New requirements
38. Bad requirements (or changing, in the waterfall model)
39. Requirements never done
40. Poor grooming
41. No plan
42. Changing needs
43. Not tested properly
44. QA too little too late
45. Poor testing/QA
46. Disengaged product owner
47. Bad attitude
48. Competing priorities
49. Loss of funding
50. Epics as stories
51. Change priorities
52. Poor quality
53. Not focused team members
54. Organizational dysfunction
55. Bad coding practices
56. Lack of full participation
57. Incompetent people
58. Single points of failure
59. Technical solution determined by Business was not achievable by Technology
60. Shifting business priorities
61. Decentralized execution teams working in silos
62. Needed expertise not available
63. Budget
64. Not enough time (again, an issue but not clearly an impediment itself...needs further analysis IMO)
65. Non-team players
66. Mis-managed timelines
67. Budget overruns
68. Poor grasp of requirements
69. Multiple priorities
70. Complete requirements (lack of)

See earlier lists for further discussion.

3 Ways a Scrum Team is managed

We think it is reasonable to manage a Scrum in at most 3 ways.

1. Self-management.

The most important way is to tell the Team that they are respoonsible for managing themselves to success.  That is, within their scope, they have to figure out what they need, and then get it.  They have to define all the details of success.

2. Business stakeholders.

The business stakeholders directly working with the Team have a responsibility to provide management over-sight. Honestly, though, what I see is that these managers usually over-manage.  They do not let the Team self-manage enough.  And this hurts.

But, if the Team is not managing itself well, they must do something.  The first thing is to say things, ask questions, but let the Team make some small mistakes.  That's the way they learn.

But if the mistakes continue or might be big, then these 'managers' must intervene.  Usually by helping with one or two impediments.  Possibly by making some people changes.  At the extreme, by dis-banding the Team.

3. Oversight of multiple Teams

There should be an oversight group.  In a small company, this might be the Executive team.  In a larger company, maybe a 'team oversight group'.

The purpose of this group is to look at each team and evaluate whether it is doing 'well enough' to continue, when compared to other Teams and other opportunities.  And, they can help a Team as well.  And resolve some conflicts (eg, two teams want the same person, and that's not possible at the same time).

One can also imagine that the business stakeholders might not do their management job, so this is a backstop to that level of management.

BTW, we strongly urge that the Team itself be there when the oversight group reviews them.  The Team can answer questions, and they can take any feedback 'back to the Team' with much less mis-understanding.  Try to keep the communication clear.  It might be ok if only the PO and the SM appear at the oversight group.  Maybe.

***

So, 3 'levels' of management.  And that is *enough.  The poor Team needs time to actually do something, instead of being managed so much that they go crazy.

In Scrum, it is pretty clear to see if they are making progress, and usually even if they are making enough progress.

It is just wrong to over-manage innovation.