Lean Agile Training | Scrum Courses, Coaching, Consulting | US Canada
Scrum Courses, Consulting Coaching, Lean Agile Scrum Transformations-Agile Software Development, New Product Development, Project Management. Follow this blog to gain in depth knowledge on scrum and agile.
So, apparently people are doing Scrum and not tracking their Velocity. Why?
One key reason: they do not see how useful it is.
Here are some explanations.
Helps the SM focus
The Velocity is the key metric for the ScrumMaster (SM).
The SM should increase the Velocity 100% in the first 6 months. Which means things have to change.
And the right things have to change. So, it brings focus the SM’s work.
The PO and the business side and the customers need to know. When will it be delivered.
Velocity with decent estimating and the MVP (Minimum Viable Product) concept provide the answer. Example: If we have another 120SPs in this MVP (this release), then we can deliver in 6 Sprints. (That is a simple example, not fully explained.)
It is VERY useful to know this. Many decisions depend on it.
The Team should be proud of how much higher the Velocity is now (compared to some prior Sprint).
The Team helped identify the right impediments. The Team, in a number of ways, helped the SM figure out how to fix things.
The Team used the improvements and actually achieved the higher velocity.
The Team can now be proud of how much more the Customers are getting (and definitely the Team should care about that).
Helps the PO (and the Team) Win
Winning in the marketplace depends on a strategy. There are potentially many ways to win: work faster, learn faster, release before the competition, etc, etc.
The more the PO understands about the Velocity, the more the PO (and the Team) can choose a better strategy to win this time against tough competition.
Velocity is by no means the only thing to know. But it is one key thing to know.
The two main levers that the PO has to increase BV delivered are: (1) help increase the Team’s velocity, and (2) increase the value of the stories, specifically the BVPs (business value points) per SP. A bit more generally, increase the average ROI per SP.
We do not wish to over-simplify the PO job. Learning and innovation and speed are also very important. But Velocity is definitely very helpful for the PO….and thus for Team success, and thus for the Team.
The Velocity concept helps managers.
We do NOT recommend giving a Team a “stretch goal” or asking them to do 25SPs in a Sprint when their Velocity is only 22SPs.
But we do recommend that the SM focus on fixing impediments (of whatever type) so that the Velocity goes up. And the Team also must help with this.
Managers can understand having a full-time SM in a Team if that SM is going to measurably increase the Velocity (I’ll say 100% in the first 6 months). Or continue to keep the Velocity at the hyper-productive level. You can use numbers to show this to almost any manager and they will agree. This is very useful.
Much harder to explain the value of a SM to a manager without Velocity.
Managers also want to know, generally, is the Team doing well. Velocity gives that transparency.
Managers want to help set realistic expectations (below and above). Velocity is a key part of that.
Managers want to help the Team be more productive, eg, by helping the SM remove or mitigate impediments. The Velocity number give quick feedback: is the manager’s help really helping?
Managers want a reasonable ROI on investing in fixing impediments. Velocity helps with that a lot, both prospectively (in getting approval) and retrospectively (seeing that what we expected actually happened).
Velocity: Don’t leave home without it.
Note: See our prior post that discusses key preliminaries.
In what other ways would you explain HOW useful the Velocity is?
Each team has a DOD (definition of done). The Team has small stories at the top of the product backlog.
When each small story, which has story points that estimate the relative effort, ..when each story is “done-done” per the DOD, then the Team scores 2SPs toward their Velocity for that Sprint. 10 stories done-done at 2 SPs per story… that would be a Velocity of 20SP for that Sprint.
It is useful to think of Velocity normally as the average Velocity over the last 3 sprints. That typically is what is sustainable into the future, and gives a more accurate picture that takes out the ups and downs of each sprint.
Is Velocity more important than Business Value?
Well, they are both important. But Business Value (in the customer’s eyes) is more important than Velocity.
But assuming we can increase both Velocity and the BV of each story (of, let’s say, typically 2 or 3 SPs), then … let’s increase both.
Are there any assumptions?
In general the people in the innovation team (aka the Scrum team) have often been badly treated. Or lived under “less than ideal” circumstances.
So, we must change that reality to include the following.
Hours must be lower, not higher, as we increase our Velocity. I’ll say a maximum of 40 total hours per week to get maximum velocity, business value and innovation. And much of that is toward “stuff outside the team” and other “lost time”. Maybe 60% is useful toward our product.
Also, the Team must be having more fun, or greater happiness, as you prefer. The Happiness Metric (see Jeff Sutherland’s blog) is a good way to measure.
It should go without say that Velocity is never achieved via cheating…that is by saying that something is done when it is not. By not fixing all the bugs, or in some other way reducing the quality and pretending to be finished. It should go without saying — but notice that I felt somehow I had to say it.
One Key Benefit
Velocity is a key measure to help the ScrumMaster see whether he/she is fixing the best impediments for the Team (or getting them fixed).
With Team and people and organizations, it is hard to see. Velocity gives purpose to the SM’s life. Helps them see. Helps everyone see the value of an SM. Helps everyone prioritze and get s##ff done. That is very useful.
His (currently) latest posts asks for a DOR (definition of ready) and then a DOD (definition of done) (visually, he uses post-its). The next post-it says “Simple (but) Not Easy”.
To me, he is saying: We should be able to use the DOR and DOD to get more working software delivered by the end of the Sprint. And yet, even though these concepts and this possibility if out there, it is not happening.
My next question: Why the hell not?
Well, first, from what I can see, this is not a universal problem, but it is a very common problem.
But, again, why not? Why is this not happening almost universally?
The reason I say it that way is that these ideas are so basic to Scrum. Anyone should be able to do these basics. (I understand that if my children (not almost adults) say “Dad, that’s basic” it is a type of insult. I am not trying to insult anyone.)
Scrum overall is hard, apparently, based on what we see. But why should this (what you have in his picture) be hard?
Here are some root causes that I proposed based on my experiences and the many questions and comments in my classes.
Do not understand Scrum well enough. This seems to be common.
Do not have enough of the skill sets to get to working product in 2 weeks (one sprint). (If software, see XP.)
Stories not small enough (yet).
Do not have enough resources (eg, infrastructure in some sense) to get to working product in 2 weeks. Or the resources do not work well enough.
Dr. Royce defined waterfall in 1970. See his paper here.
His son, Walker Royce, said that waterfall was over, and said we are on to iterative and incremental now. He said this before we started calling it agile (before the Agile Manifesto was written). See his book here.
Long ago, in the 1980’s, the DOD established standards that mandated waterfall.
But since then, and for 10 years now, DOD has gotten rid of those standards, and is trying to learn to become agile. And the standards now mandate agile. Although I am not sure that the DOD people and culture are really there yet.
So, what is the problem or the question now?
Well, there is no longer a debate about waterfall vs agile. That’s over.
Side note: It can be said that agile is waterfall in very small sashimi slices. OK. But that is not really waterfall redux.
The problem is: we have lots of different agile flavors. We have scaling. And we have unprofessional agile. (There are many other names for it, including Flaccid Scrum, Scrum-Butt, etc, etc.) I consider the later to be the biggest problem. It gives “agile” a bad name. And it is silly and unprofessional.
Now, between good agile and unprofessional agile, there really is no debate. Well, the debate is “when does it become unprofessional?” And the answer to that probably depends on both the people and the situation.
Where is the real debate?
I think, right now, it is over a few questions.
What are people? And how do we best work with them?
How much process is enough, and when does it become too much?
What is the role of the manager and other people outside the team?
How fast can we change an existing org? Where is the best place to start? And out how far do we imagine the future?
What is the best kind of team, and what are the most reasonable trade-offs?
Assuming the team needs certain kinds of skills to be “really” successful with agile, what are those skills (or what is that knowledge)? And then how and when do we get that to them?
Note that question #3 implies that everyone in agile agrees on the value of a team, and what a “team” really is. I do not think that is settled…as implied by my questions #1 and #5.
Note: One of the current questions is about scaling. Especially, how do you have 3+ team work together. This debate is not going well, in my opinion. Too much emotion and not enough facts. I feel this debate is covered, to some degree, by my 6 questions.
I am not sure these are the best 6 questions, but they are close. In my opinion.
This is our basic picture of a single Scrum Team working on one release. (For example, this picture does not try to address ‘scaling’, if that were relevant.)
Let’s start with the Product Owner, who is responsible for the quality of the Product Backlog.
Then we mention the ScrumMaster, who is responsible for aggressively attacking the impediments. Or leading that charge. Specifically, the SM should help the team self-organize and self-manage in a competent manner in an environment that typically is not as supportive as we would like. The SM helps remove the impediments.
We have of course the Implementers. They do the real work of building and testing the environment.
Of course we have a Vision, which we all are working toward.
We have a Product Backlog that makes the work concrete. The basics are a simple list of all the work we might do, in order. Mostly the features, but really anothing this Team must do.
Representing the customers and the business side we have some part-timers. We call them Business Stakeholders. The essential thing they must do is showup at the Sprint Review and give good feedback about what the customer will want in the future. No one knows the customer that well, not even the customer, and especially not about the future. But these BSHs are better than most.
But the key group we want to point out is the Chickens. By chickens we mean part-timers who help the Team, and mostly help the Implementers in building or testing the product.
These circles that represent chickens can represent many things. First, at a high level, they represent the idea that the Team is never totally autonmous. In my experience, the Team is always dependent on people outside the Team. The Team never has all the skill sets, for example.
Who can these people be? A circle can be one person. A circle can be a group (eg, a department or function). A circle could be another Scrum team. A circle could be a vendor. A circle could represent people in many different configurations.
What might these people do for us? Many things, alnmost anything that one might imagine. A person could advise us. A person could have knowledge. A person could work with us. A person could do some work. A person could produce a widget that goes inside our product. Many possibilities.
The key thing is that we must put them in the picture, identify those people, name names. Then the Team must figure out how to manage people who do not have “skin in the game”, who do not think that the product we are working on is their main priority. This is trouble, or at least often can be.
I have already started talking, but want again to continue talking about an easy subject: Transforming a company to agile.
Well, not so easy. But not as hard as some people think.
‘A journey of a thousand miles starts with one step.’
We are too easily discouraged by what seems a daunting task. We too readily make the mental mistake: “I have to have it all figured out before I can start.” Sorry, but when working with people, you know that ‘having it all figured out’ is not possible. One cannot, one should not, and one will never control other people.
Still, there are things we can learn and things we can do better to make (or influence) how the agile transformation will unfold. We are not all powerful. That is not the same as saying we are completely without influence and smarts and wise things to say and do. We have our talents.
I and a colleague are thinking about building a course on how to do agile transformations.
Some basic notions:
* change in organizations is hard (but far from impossible)
* there is much existing knowledge on how to get change to happen and how to get it to stick
* this knowledge is not simple
* agile transformation in some sense affects ‘everything’
* it is necessary to make a list (of work to do) and prioritize
* for many reasons, it is useful to work as a ‘transformation team’
* it is useful to learn some theory. Put another way: trying to learn from experiences at other places
* it is useful to learn and do and get feedback and repeat (PDCA)…in executing the transformation
* top-down or bottom-up? Yes!!
* although there is no ‘one size fits all’ answer, there is a basic framework, and some very common patterns
* for an agile transformation, our bias is that all change agents (well is that the best term?) must actually understand, in a real way, the key stuff they are recommending changing to. Ex: They should have actually been in a Scrum team, as a pig.
* ‘people don’t resist change, they resist being changed’.
* for more than one reason, in general we want the ‘objects’ of change to take some decisions about what the change is. (Freedom: what an original idea for humans!) This is not a stupid ‘everyone is exactly equal’ notion. Nor ‘let’s find the stupidest guy around, and let him decide everything.’ Perhaps more to discuss.
Some notions about the course.
* the course is only useful if it helps the change get more results. Just teaching some people is not enough.
* we define change agents broadly
* the course discusses some key concepts and theories
* the course does exercises
* a workshop, practical and specific to your situation, is included
* basic patterns of new idea adoption
* setting a scope for a transformation team
* determining the effectiveness of a transformation team
* what is a reasonable price for agile transformation?
* how do we convince the ‘buyers’ to take the plunge? How to convince them to continue to invest?
* where does communication fit it? How do we know we are doing the right amount and doing it effectively?
* what are some tools and methods the transformation team can use to ‘make’ the transformation happen?
* how does the transformation team identify emerging impediments to the transformation?
* is there a connection between the transformation team and the ‘real’ agile teams? If so, what and how?
* is there a connection between the transformation team and other groups in the firm? If so, what and how?
* how does the transformation team do adaptive planning, and explain adaptive planning, for the transformation?
* how does the transformation team measure success?
* what about scaling?
* what about transformation in multiple locations and time zones and cultures?
Alisha Parry recently read Jeff Sutherland’s book, “Scrum: The art of doing twice work in half the time.” Here are some of her observations that she shared with a work colleague.
1. Bugs take 24x as long after you wait to work on them. We have seen this even on Kronos, as we have previously discussed.
2. A new hire on the team dramatically slows down velocity due to needing to train them up and spend time working with them, [time] that would otherwise be spent on other sprint work.
3. Scrum for educators! I loved this section, especially coming from teaching previously. When I started reading the book I kept thinking how cool it would be to implement this in the classroom and then, lo and behold, they had a whole section dedicated to talking about this in the book. I think it’s great!
4. Happiness rating. We’ve already touched on this a bit too. It seems very important to have a true happiness rating and an idea of where employees lie on that rating scale to have a successful company.
5. Comparing scrum numbers [story points] to dog sizes. With switching over to a new ticketing process, hearing this really helped me understand how pointing our tickets should work. In addition, people are awful at estimating time!
6. (Discussion Point) To piggy back off of that, during our sprint plannings I feel there is a lot of time wasted on discussing pointing. Let’s say we throw 3, 3, 3, 5, 5. We then have a discussion, sometimes for a few minutes, about whether it should be 3 or 5. The book says anything within 2 steps (Ex. 2, 3, 5 or 3, 5, 8) should just be averaged. Our 3, 3, 3, 5, 5, would then turn into a story point at 4 points and discussion time would be at a minimum. It does say if it’s more than 2 Fibonacci steps (1, 3, 5 or 3, 5, 13), then the outliers (people) need to explain why they [voted that way] and discussion should be had around this before determining true points for a story. Averaging points seems way more efficient though, than the way we are doing it right now.
7. (Discussion Point) The section about Value was very interesting to me in its entirety, but it gave me an idea I wanted to present. I’m speaking mostly for my team when I say this, as I don’t know how other teams work, but we regularly have ideas for how to make things better, but no time to implement them during a sprint. For example, microservice consolidation, creating our new tracer bullets, etc. rarely have a place in our sprints. Product dictates what we do. I think teams would greatly benefit from a “Teams Choice” sprint once per quarter. This would even help in the long run with efficiency and teams would feel like they own what happens more often than we do now. We can definitely talk about this more if you’d like to, this is kind of a brief overview.
8. People are awful at multitasking and interruptions greatly slow down progress. This is coming from a team that has “data lag red flags” pretty regularly. When others are looking in not fully understanding what is going on. This happens to us a lot, because those looking in are seeking clarification or misunderstanding how severe the lag really is. There is definitely a lot of “interference” from others (Product, QA Managers, Support through QA Managers) that slow down our sprint progress hugely.
9. Piggy backing off of this, I found it interesting that the car building would have all bugs planned in the next sprint, not thrown into the current sprint. If it isn’t a dire need, it is held off and planned instead of interrupting the current work being done.
10 Observe, orient, decide, act. [OODA loop] Just in general, I liked this.
11. (Discussion Point) Kind of building off the happiness rating, I think it would be beneficial to have monthly/bi-monthly peer reviews. This stemmed as an idea from Valve as well. I don’t know exactly how it would be implemented, maybe through a similar survey to the pulse survey and the reviews get sent to managers? Not sure, but I think raw feedback from team members on other team members would give great insight to managers in areas they may not see and if it’s in a survey format it would give those who are on the quieter, more reserved side a chance to speak up.
13. Change or Die. Again, just like it in general.
14. Shu, ha, ri. Great concept for learning, implementing, and mastering.
15. Focusing on team productivity not on individual productivity. The worst team was 2000x slower than the best team. That’s crazy!
16. Keeping teams [within] 5-9 people. Connections are n(n-1)/2 which becomes way too much for our brains to handle.
17. When we talk about ourselves, we talk situationally, but when we talk about others, we talk about who they are personally. I know for sure I do this, but never actually thought of it this way before. It was eye opening.
18. People only have a set number of sound decisions they can make in a day!
In the first course (almost always the CSM course), I have people wanting, in simple terms, one of two things. With little compromise between.
One: Real Scrum.
By this I mean everything in the Scrum Guide plus all the better patterns around that.
Two: Easy Scrum (aka Half-baked Scrum)
This is Scrum compromised quite a bit to fit quickly and nicely, after many deletions, into your current organization.
Those are the two options. Let’s talk further about what I am calling Half-Baked Scrum. (Yes, I might be biased. But my bias is based on wanting you and your team and your customers to have a much better life.)
Several things can be said…
a. Easy Scrum can be implemented quickly in your current environment. This definitely feels like an advantage.
b. It is much less effective than Real Scrum.
c. Real Scrum feels impossible to implement (quite commonly). To be fair, it can be hard and it can take some time. And it takes, virtually always, some courage and a lot of persuasion.
d. To be fair, Half-baked Scrum is usually a nice improvement over what your firm is doing now. It is tempting.
e. Most people who are requesting “easy” over “hard” — do so usually because they have no idea of the benefits of Real Scrum, and how much difference it can make.
Anyway, Half-baked Scrum is interesting in some ways, even though it does have a bad name (I think).
But Real Scrum, once you get it to happen, will serve you better.
The key problem for me is two-fold.
First, in the first course particularly I am responsible for introducing you to Real Scrum aka all of Scrum, and Full Scrum. Along with a small set of the better patterns that should accompany it. And it takes me almost a full two days to do that.
Second, when they say they want Easy Scrum, what that really is varies a lot, depending on their situation. The truth is, what Easy Scrum would be would vary for each person and each situation, to a fairly notable degree.
And that leads to a problem for me. It takes too long to explain. There is no way I could explain Real Scrum and Easy Scrum both in two days.
So, what is possible?
First, I want the students to understand clearly what Real Scrum is.
Not with the idea that they will do it all immediately (usually not possible), but with the idea that they will learn it, and strive to get it fully implemented soon.
And we take some of the time in the course to talk about how to start implementing Scrum in many of the common situations.
I hope this now explains my attitude in the course, but more importantly my attitude about how you go about implementing Agile-Scrum with greater and greater success at your place.
Abid Quereshi said this recently:
‘”Agile transformation” is another one of our made-up terms like Agile BA, Agile Tester, Agile PM and Agile Coach.’
By this he means, as he explained, that people use a term, but do not agree on its meaning, or that the meaning is so broad as to be almost meaningless.
Lots of people are talking about Agile Transformation. It is a very broad word, and used in many ways. Because the meaning is so broad and the word is used by different people to have notably different meanings, it is, as Abid says, almost meaningless.
Let’s attempt a definition that is narrower than usual. This is not an agreed definition, but rather a working definition by Joe.
In a large Department or Division (say 300 people), Agile Transformation is having “everything” agile, so that “all” the people doing new product development are using Agile (defined most simply as Scrum plus other things). We do not literally mean all people, but a very high proportion are in Scrum teams. The group includes both Tech people and Biz people. And some, outside teams, are managers and individual contributors of other sorts. But mostly those other people support the Teams.
Success with Agile Transformation means that the culture (at least around new product development) has become based on Agile Principles. (I think this idea is right. How to define it as an hypothesis that can be proven is hard.)
Now, the overall point of Agile Transformation must have a higher purpose. We think that purpose might be defined as attaining higher overall business goals. These might be things such as: higher revenue, more profit, higher customer satisfaction, higher quality, more happiness for the employees, etc.
So, an Agile Transformation cannot be said to be really successful unless those business goals are in some sense higher.
Note: I narrowed Agile Transformation to 300 people (or so) at a time. I think this is key. I said Agile Transformation must always be seen as a means to achieving key business goals. Key, I think. Culture is important; again key.
No silver bullet
Let’s be fair. Agile is not a silver bullet. Other things than Agile can have have a significant impact on business success. Examples:
Quality of our business ideas
The Business cycle
But have we really defined agile and agile success?
We have not said which agile practices the Teams are doing.
We have not said what the agile principles (values) were and how we would know if they were well socialized with the group. We have not said if the agile principles have led to good actions and then to good results.
Outside the teams, we have not defined how it was organized nor practices we might be using in the larger group.
You start to see how complex Agile Transformation is.