We have put together some Lean-Agile Resources on this page. Please give us your feedback and suggestions.
Some of us in the Agile community think: an organization’s culture needs to change before agile can be fully adopted.
This certainly seems to be true.
Let’s define this more precisely. The idea is this:
Before a company can realize the full and extreme benefits of lean-agile-scrum, it must change its corporate culture to be consistent with lean-agile-scrum values and principles.
This can seem a daunting task.
But, first, what is culture?
To me, it is that air in which we live and breathe and have our being. Well, not exactly that. It is the culture of the main group or groups within which we live. It is what is in our heads, as a group. It is values and norms and common behaviors.
So, it includes the idea that we are not individuals (so much), but rather we are more ‘groups’, and that the key ideas or values or principles or norms of the group ‘control’ to a large extent, our behavior. Without our even thinking about it.
Now, from our point of view in terms of the change, in many ways, the new behavior is more important than new thoughts (or subconscious thoughts or feelings). But we want the people to be autonomous, and ‘do it on their own’, so we want the thoughts or feelings to be there, so they naturally do it, naturally act agile, on their own.
Moreover, we want the broader culture to be consistent with agile. With lean-agile-scrum. People typically find, if they do things consistent with the culture, they seem relatively easy. And, if you do things counter to the culture, it usually is hard or harder. So, having an agile culture should mean that agile will be more successful. Other things being equal.
Ways of changing
Asking people to change their culture is difficult.
Well, clearly to ask itself is not difficult. But to ask, and then expect results, and then to know if results actually occurred…that is difficult.
Let’s consider 3 days to make cultural change happen:
1. Talk to them.
Depending on your point of view, this is either remarkably successful or remarkably unsuccessful.
I mean this: My expectation is that normally this should have almost no impact. And yet, for a few people, it can have an impact. Sometimes. For a period of time. So, compared to my expectations, this can be remarkably successful, sometimes.
There are many ways to talk to them, or with them. Many different contexts, different people who can do it, frequency, etc, etc. A lot more to discuss than we will discuss here today.
From another point of view, many people expect this approach to be very successful. And it is remarkably unsuccessful.
2. Get them to act and ‘reward’ their good behavior.
Pretty close to classic behaviorist theory. Maybe it works. It is not tried often. And, it seems, it must be tried a lot to have it start to replace the old culture with the new culture.
Actions come in many shapes and sizes, including speaking original words. And rewards come in many types. Rewards must be close in time to the action.
Frankly, this is treating people like monkeys. I don’t want to believe in this theory. But it is there.
3. Have them experience something
What you want to do is get them to help you create the new culture. You teach them a bit, and then they become self-acting. By teaching themselves things, by building the culture themselves.
And it turns out that if you are clever, you can start to build this self-reinforcing system.
But, according to Kotter, it starts with a gut experience. An experience that is fairly profound. And that gets them to commit to changing themselves. Kotter calls it ‘a sense of urgency.’
Let me say again. Changing the culture is the work of many months (or more) for a group of people, and then the new culture will start to replace the old culture (or, ultimately, be overwhelmed by the old culture). So, it takes many months and many people before it starts to be self-sustaining.
So, given the likely counter-action by the original culture, what you need is not one experience per person, but multiple experiences. Over several months (or longer).
Then, once the new culture is established, it must be sustained.
If it is a culture of mediocrity, then sustaining it is less of a problem. But if it is a culture of high achievement and difficult tasks, it can take extra energy to maintain it at a high level. (I think this is the case for lean-agile-scrum. It has many pleasures, but it is demanding in terms of energy commitment and overcoming of obstacles.) Now, a focus on the successes and pleasures can clearly be part of sustaining the new culture.
Let me make clearer what we are doing with this last method. We are not just asking them to change. We are asking them to join us in changing the culture. Maybe quickly, maybe little-by-little. But we are asking them to participate in ‘making it happen’. Over time.
Here is where we start to bring in the word ritual.
So far I have over-simplified. To explain some key basics. Much that I dd not say, but a start in setting out a basic framework.
One tip bears repeating: It is easy to start out to ‘change the culture’ and end up accomplishing nothing. Be careful. Pick your battles. Prioritize. Get small wins. Build on progress.
It is, in many ways, a battle in the air over ideas. But make it concrete and tangible too. Show the new culture in actions. Then others can help you.
Lastly, let people tell you the truth. As one example: If they can’t explain well why we do a specific thing in Scrum, do not punish them for being human. And give them some support. Maybe a local person in their location to support the change. Changing the culture is not easy.
Why do we want to deliver fast, and then faster?
Well, the first reason is…that’s what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.
The second reason: time to market. In this context, I mean we need a good poduct to market before the opportunity goes away. Before the competition beats us there, or before the most important problem has changed.
Third. More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped “we need to deliver faster than the next re-org”. This meant within the next 3 months.
So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.
But there is more. We need to deliver faster because we get more feedback. In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.
This minimizes risk. This minimizes WIP, whose value…if we wait long enough…will always eventually go to zero. So, we have minimized the potential loss in value of the WIP, the work-in-progress. We have reduced the risk.
All these reasons that make us want to deliver something faster.
Yes, it must be a minimum marketable feature set. But we are learning that ‘minimum’ is smaller than we thought.
Deliver faster. This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.
Then the question becomes: how do we do that?
As discussed in the previous post on Release Planning, the user stories are now ordered.
(Please see this post for a list of all the posts on Release Planning.)
Now we must complete the Release Plan.
So, we must make the trade-off between scope and date.
There are three ways to do this:
1. Fixed Release Date. We will release every X months or Y sprints.
Some teams or firms prefer to have a fixed release date. It makes things simple. It makes managers and others realize that we will release. They only question is exactly what will be in the release.
2. Fixed scope. We will release when all of the scope (all the stories or PBIs in that scope) is/are done.
3. Trade-off. We understand our velocity and go down the Product Backlog a ways. And ask: two sprints, umm, how many features are done? Ok, three sprints, how many features are done. Ok, four sprints, umm, customers would really like to see another release, the market needs it, but do we have enough? Ok, five sprints, umm, I think we have enough. Let’s shoot for that. — It is that kind of trade-off.
This requires that we know our velocity.
With an existing team, you might already know their velocity. With a new team, you must guess.
So, we do a calculation to get an educated guess.
First, for the 1 story point reference story (for effort)… how many ideal person days would it take. The Team huddles around the story and reaches a decision. Imagine the number is 1 SP = 1.5 ideal days.
Imagine the Team has 6 doers (of real work).
Imagine the Team will do 2 week Sprints.
Let’s assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of the minutes are usable for the project. The other minutes are used talking about the game, taking breaks, eating lunch, getting interrupted, answering questions, reading the email, going to company meetings, etc, etc. Maybe some work, but not work on this project.
2 weeks = 10 days.
6 x 10 = 60
60 x 60% = 36
36 x (1-40%) = 21.6
21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.
We subtract the 40% has a start-up “cost” for the 1st Sprint. The Team is learning Scrum, the Team is “forming, storming, norming, performing..”, the Team always wants to over-estimate what they can do in a timebox.
For the 2nd Sprint, we subtract 20%. For the 3rd Sprint, we subtract maybe nothing.
You may find that these rule of thumb numbers need to be adjusted for special situations. But they seem to work for most start-up teams.
36 x (1 – 20%) = 28.8
28.8 / 1.5 = 19.2 story points for 2nd sprint
36 * (1) = 36
36 / 1.5 = 24 story points for 3rd sprint
And so on…
I tend to put pressure on new Product Owners to release earlier. They are mentally too tied to the concept of the 100% – 100% rule. That nothing can be released until everything is done. This is almost always just wrong. Hence, I always ask for an earlier release.
Once the PO and Team agree on the scope and date, we then have to talk about the “communications plan”, as I call it.
If the Team works with a manager who truly understands adaptive planning (meaning that the current plan will be revised and improved every sprint… this is only the first guess at the plan)… then tell that manager the truth. Here’s what we guess, this is what we are worried about. This is our feeling about how it is likely to change. And maybe we have contradictory feelings.
But often some key managers do NOT understand adaptive planning. These “tough” managers (or customers) want you to give a fixed date, and then deliver to that date.
Then you are stuck. So, we have to do what we used to do in waterfall. Add some “buffers” (aka padding, etc, etc) to the date. For “problems”, for new stories to be identified later, etc, etc.
It is hard to guess how much buffer to add. We have no additional magic.
But, we do strongly suggest that you protect yourself and your Team. Do not get them in a situation of a Death March, trying to meet an impossible date. More about this later….
And then we talk about, “ok, how will we communicate the date?” (Almost always, the key issue is the date.) You have to start setting expectations that the date will change if other things change (substantially), and they are likely to change substantially. This is not one conversation by the PO, but a series of conversations by and with many people. It is over time that the start to see and feel the power of adaptive planning.
For some of you, the issue is not so much “communications plan”, but “what do we put in the contract”. Too big a subject for this post.
Finalizing the Plan
Assuming you have “business stakeholders” as I described them earlier, then always you have to review the release plan you have with them. Get their buy-in or comments or adjustments. This of course may affect the communications plan.
So, this is most of the basics. A bunch of issues we have not addressed. Some I will address in the next post.
We have this idea in Agile, that the Team should self-organize. This is an important idea. And also an important occurrence (eg, the reality precedes the idea).
In Agile, self-organization is compared to command-and-control.
We think self-org is an important thing to study, both in general and in your Team.
Well, one, because it is just right. People are free, and self-organization is saying that the Team is allowed to be free.
I guess this needs to be explained a bit. Some will say: well, the company has bought their time as employees, so the company gets to define what the Team does. Well, let is concede this at a high level; let us say that the company may define the vision or the goal or the general product. Perhaps even the user stories. The Team members are not slaves, but we can assume that, as employees, they agree to do the company’s work for pay. A contract.
But, devising the work, figuring out how they will get to the goal, they should have the freedom to do.
The second main answer is: self-organizing humans tend to do better work than human ‘slaves’ (humans directed by one or a few command-and-control people).
There is lots of evidence of this. The first book I recommend is The Wisdom of Teams by Katzenbach and Smith. This is a rather old book. But the basic evidence is that a self-organizing team out-performs, almost always, an individual. And to such a degree that the extra cost is well worth it. But, you must given them some degree of ‘freedom’.
There are also a lot of more recent evidence.
Note: Some people say that a free enterprise system is mainly characterized by (mostly) private ownership of capital (means of production). And attribute its successes or failures to that. Others focus on the freedom of individuals to make their own decisions (much like the “wisdom of crowds” idea) and on the view of the national economy as a complex adaptive system, trying to accomplish high-level economic success via many individual agents (people or companies) making their own decisions. In our view, successful free enterprise countries exhibit many of the successful characteristics related to self-organization.
Lots of managers have been taught, explicitly or implicitly, that the ‘workers’ are dumb, and the manager must tell the worker how to work. In our view, especially for virtually 100% of knowledge workers (our domain), this is very very incorrect teaching. But it is nonetheless, what they have been taught.
Now, some of them also understand freedom to some degree, and understand that they want the people in their group to ‘think for themselves’. But, we can say with relative assurance, most companies have a lot of people who are relatively command-and-control in their style.
And, in pressure situations (our common situation), they want to use too much command-and-control.
Again, this is not true of all managers, but of many. It depends, in part, on the company’s culture.
It is hard to convince these people to be patient for self-organization.
Teams that won’t self-organize
This is seen in real teams.
There seem to be several root causes. One, the team has been beat down by command-and-control managers so much, that they have ‘forgotten’ how to self-organize. Another: that they Team does not believe it when managers say ‘self-organize’. Another: The Team is fearful that by self-organizing they will be ‘held accountable’ with punishment a likely outcome. To avoid pain, they refuse to self-organize.
Whatever the reason, two things can be said.
Many Team (perhaps with Agile coaches) do eventually break out from being ‘stuck’ (not self-organizing).
And some Teams may take a very long time or perhaps never do it.
The key advice is this: If the Team will not self-organize, or seems to want to self-organize to mediocrity, then a good manager should intervene. Temporarily.
Perhaps prior key advice: Be patient. Often Teams will self-organize in two or three sprints. Keep talking about it, and ask them if they need help.
Third advice: In the view of some (including me), some Teams lack some key skills to self-organize. For example, a new junior Team may not know really how to break down work into tasks for the sprint planning meeting. Sometimes ‘holding their hand’ as they mature is a very successful approach. And 3 or 4 sprint later, they can be very good at self-organizing their own Sprint Backlog.
Learning to decide as a Team
I think each Team learns how to decide.
The first, most useful thing, is that everyone in the Team gets to offer input on a decision.
Next, the Team needs to accept that no decision is ever perfect. Thus, decisions in general must be made, perhaps not always quickly, but promptly.
The Team needs to understand the impact of decisions on the morale of the Team and on the success of the Team.
In our view, most teams go through a forming and storming period of decision-making. And then later get better.
Good self-organization… and better
Lots of Teams seems to self-organize well.
What is also common is for most Teams to plateau.
In part, we may say that a root cause is that most Teams want to reach a stasis… a place where things are balanced and where change slows down.
But have they reached the height of improvement? We think not. Some Teams have reached much higher heights. And some Teams keep on improving.
There seem to be two main factors (or sets of factors):
* magic — or, more accurately, a bunch of things that are hard to describe.
* a bunch of factors that people talk about, and some teams study and work on
Some of these last factors seem to be quite ‘soft’. Love, listening, creativity, heart seem to be among them.
If you have never been on a good team, it is hard to understand what self-organizing is all about.
Within the Team, it might be rather rough and ready. But a lot depends on the specific individuals in the Team.
This is a “just enough, just in time” concept.
OK. So, it is something ‘written’ that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need. To get it done right. Quickly. High quality. Etc.
What might it contain?
Well, anything useful.
I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.
It is simplest to think of the Agile Spec being ‘written’ ‘one sprint ahead’. And being checked for ‘ready, ready’ before the Sprint Planning Meeting. But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.
Maybe hand-written, maybe on a wiki. Maybe in a Word doc.
Who writes it? Well, the best people, of course (self-organize!).
It might hold:
- the acceptance criteria
- a business flow
- a list of business rules
- a wire frame(s)
- a mock-up of the screen (if that means something different to you)
- a simple use case kind of flow (not all the darn UML use case stuff… just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
- a data flow
- new data elements (or whatever you guys call them)
- key data elements and key values in this context
- a screen flow
- a simple design picture
- a data flow, maybe simplified
- an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
- anything else they may find useful to build it quickly and for it to EXCITE the customer
Any one Agile Spec will NOT have all of these things.
It does not repeat the usual BS that we used to put in specs. That no one really read.
It does not say all the stuff they know well already. It is not trying to be ‘comprehensive’.
We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.
We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.
And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).
For some people, who maybe had too much fun in college, we need to write or draw more.
For some people, who maybe took their Ginkgo today, we need to write or draw less.
It is hard sometimes to create. We wonder, will our darlings ever survive. I have spoken already of a book called The Courage to Create by Rollo May.
Now I want to show a short poem by Shelley. Ozymandias, it is called.
I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
“My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!”
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.
Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom. You will note that Shelley, the great poet, was not daunted by this vision of despair.
I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away. (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)
I hope that you do not seek that fickle goddess, Power. Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).
But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly. A new product will come along and charm them a different way. I am sure any of you can think quickly of an example.
We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.
I will close with this quote from Henry Ford:
I cannot discover that anyone knows enough to say definitely what is and what is not possible.
Scrum requires a real team.
The word ‘team’ is often used, often in different ways. So, let us define it.
According to “The Discipline of Teams” by Katzenbach and Smith, this is what you should look for:
1. A meaningful common purpose that the Team has helped shape.
2. Specific performance goals that flow from the common purpose.
3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.
4. A strong commitment to how the work is done.
5. Mutual accountability.
For more discussion, see The Discipline of Teams.
The team needs to be small (~7), stable, cross-functional, and self-organizing. The team is in it together. And should help each other.
In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team’s goals.
All of these team characteristics together are key to starting Scrum. Got to start with a real Team.
Note: Not everyone wants to be on a Team. And for sure, not everyone walks into the office knowing how to act in a real Team.
Here is an entertaining article in the WSJ. About people “types” that kill meetings.
Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.
But as soon as you have people and meetings, you can have some….umm…interesting times. So, may your meetings not be interesting this way.
First, unlike some in the agile community, I think managers can and should be useful in lean-agile-scrum.
Still, there is a lot of evidence, on many levels for two propositions:
1. Some managers can be very detrimental to a lean-agile-scrum implementation.
2. Many managers have not been well trained in how to manage. In fact, what they have been taught seems to be, to a large degree, the wrong stuff. (At least, it seems, in the US. In other countries, this may be better.)
So, we agile advocates have a long way to go to get all of management ‘fixed’. I mean both middle and senior managers now. (Yes, the solution for the middle managers might be somewhat different than the solution for the senior managers.) On the right page with the right attitudes and practices that are consistent with lean-agile-scrum.
So, a few quick ideas on how to fix this:
1. Check out the “Stoos” group. A few are a bit too radical for my taste, but that group is working on ‘management’. They have useful ideas on this problem.
2. Respect change. It is hard. It does happen. You cannot always make it happen, especially on your own schedule. But sometimes, either before or after you want, people will change. And even in the direction you want, due (partly) to the efforts you made. …Do not let yourself get depressed, do not give up.
3. Respect the people you are trying to change, and that, at least in some ways, their concerns are legitimate. At least from where they are coming from, there is typically some internal logic to the way they think. … I find this is hard, because I can so palpably feel the damage these people are doing. It feels like they are trying to be evil sometimes. Certainly stupid. And I grow impatient. But mostly there are not (evil); they are usually trying to do they best they know how.
4. Look (again) at the standard change books. Kotter’s books. Fearless Change by Manns and Rising. Others (if you prefer). Many great ideas about getting people to change. Most of the following are discussed well and at length in these books.
5. Make the case. Repeat it often. It starts with a Sense of Urgency.
6. A sense of urgency, to me, starts with one person having a passion that, dammit, things have to get better. And conveying that passion. Maybe in a quiet way. Certainly in a respectful way. But in more an emotional way than a ‘numbers’ way. Although numbers usually need to be in there as well.
7. Use some experiences. Maybe from articles. Maybe from nearby firms. Maybe from your own firm. Data of one sort or another. There are tons and tons of great articles about lean-agile-scrum now.
8. Five books for managers.
Toyota Production System by Taiichi Ohno.
Radical Management by Stephen Denning.
The Power of Scrum by Jeff Sutherland et al.
Software in 30 Days by Schwaber and Sutherland
Drive by Daniel Pink.
9. Motivation. Often the key, I think, is they misunderstand motivation. Particularly motivation for knowledge workers. This is why I think Daniel Pink’s book is so useful.
Please comment here. I think this is a hard problem. If we knew the answer well, this problem would be a lot better now. So please suggest better things.
We are also discussing this topic in the Agile Business yahoo group. Please join us.