Setting goals for agile projects is trickier that setting goals for waterfall projects. As I mentioned in an earlier letter, for waterfall projects it is possible to set the goal in the form of a feature list to be delivered. This approach has several drawbacks - it does not guide the thousands of micro-decisions that are made, it gives no sense of purpose to support the drive or inner motivation, and it gives no guidance for evaluating whether the money, time, and effort was well spent.
However, although all these problems, and although the approach is not advisable - it is still possible. The project management mindset and tools for waterfall projects are applicable for reporting project status or following up visavi a feature list. It is also possible to evaluate success by checking whether everything on the feature list is implemented.
Well, I still think it would be better to evaluate whether the project created some value.
Now, ridiculous as this seems it is still industry standard.
The CHAOS report 1995 from Standish Group might be one of the most cited reports in system development. According to its statistics only 16% of software projects succeed. In the 2012 report this has been updated to 39%. And they collect data from tens of thousands of projects so the figures should be pretty reliable.
Now, this seems scary and low, but only until you check out their definition of success."Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified."OK. Not a word about actually getting value for the effort. Remember the on-line bookstore where they wanted others-have-bought recommendations to increase the number of books customers. Now, imagine they implemented the others-have-bought recommendations, but the customers did not buy more books anyway. Is this project a success?
Well, you have spent lots of money building something, but made no money from it. To me it sounds like money, time, and effort down the drain - not as a success.
To Standish Group, it is considered a success.
On the flip side, imagine the project realising that a simplified "search similar" would increase the number of books each customer buys. Imagine further that this feature would be much easier to implement. So, the project decides to implement that feature instead. And the number of books sold per customer increases 0.4 on average.
Spending less money, time, and effort on something else than originally envisioned, but still getting the benefit - that sounds like success to me.
To Standish Group, it is considered a failure.
Thus, the figure 16% or 39% actually says nothing at all about the state of software projects.
So, Standish Group is probably filled with smart people. Why did they not evaluate software projects according to some meaningful metric instead? Most probably "generated business value as specified upon funding" would be more interesting.
My guess is that too few projects actually stated an envisioned business effect, so analysing those projects would give so little data that it would not be possible to make any significant conclusions.
So, instead of measuring something that would actually matter ("fulfilled envisioned business effect") they just measured something that could be measured.
Now, from the second example, where the team implemented another feature than originally envisioned, it is also clear that this approach is an absolutely worthless way of evaluating agile projects.
PS The CHAOS 1995 report has been republished openly available for academic purposes. It can be found at http://www.projectsmart.co.uk/docs/chaos-report.pdf. The 2013 version can be found at http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items. The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.
Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done. Scores therefore give a sequence to jobs. The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”. The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.
In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners. The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
Old habits die hard. When a developer suddenly steps into the Tech Lead role, it is not immediately clear what to do differently. Instead of taking on the Tech Lead responsibilities, they stay heads-down writing code. The more code they write, the better they feel that they are still contributing to the team. Other Tech Lead responsibilities are neglected in favour of writing code, even though they must still be fulfilled. A Tech Lead must spend enough time on non-coding responsibilities. They must ensure a Technical Vision exists, and the development team are working together towards the same goal. Both of these activities require more than just code-writing.2. Not spending enough time writing code
The “Tech” in the Tech Lead role is there for a reason. It is too easy for a Tech Lead to sit in endless meetings instead of spending time with the team. They lose awareness of how the code is evolving and which patterns or anti-patterns emerge. Without an up-to-date awareness of the system and its technical constraints, a Tech Lead cannot effectively lead the team. A Tech Lead who codes has a better understanding of technical problems or opportunities whilst building and maintaining trust with developers. Writing code keeps the “Post Technical” label away.3. Making all the technical decisions
The first time Tech Lead may feel compelled to make all decisions. To compensate for writing less code, or to demonstrate their new role, they give input to any and all decisions. Unfortunately this behaviour discourages the team from making contributions. It sends the message to the team they should do what they are told, or not think, even though a team member has the better solution to a particular problem. An effective Tech Lead knows when to give input, knows when to make decisions and when to step back and allow the team to take more ownership.4. Talking only Tech
A Tech Lead interacts with many people who sit outside of the development team such as people from marketing, finance or a product division. These people usually have very limited technical knowledge. Talking to them in terms of frameworks, libraries and tools adds confusion, frustration and simultaneously signals a lack of empathy. A Tech Lead must find a way to communicate ideas in ways non-technical people can understand such as using analogies and using terms others can easily relate to.5. Constantly reacting
A new Tech Lead will find themselves juggling several activities at once. The bane of a developer, interruptions, becomes an everyday occurrence. A first time Tech Lead can simply react to the loudest or most alarming situation, even if it is not the most important. Over time, the Tech Lead develops better time and task management skills in order to manage the many demands.
If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
As some of you may know, I’m building a boat in my brother’s garage. We had a big milestone the other day: we finished painting the bottom and rolled the boat over to finish the topsides. From a distance it looks great!
Up close is another story though. Up close you can find ripples in the paint from where the fiberglass wasn’t sufficiently well sanded. There are other places where you can see fine lines in the paint due to underlying patterns in the filler compound. Add to that the fact that the paint has rough areas where the roller left a pattern. And don’t even get me started about that flat spot.
I see all of these imperfections and more. It’s pretty rough.
I’ve worked with teams like that too. From a distance, everything looks great. You are hitting your milestones and everyone is pleased.
But get close and you find all sorts of flaws. They’re not using story points. They won’t keep their burn down chart up to date. They don’t even know what an acceptance test is. They’re pretty rough. Maybe we should just keep them in the garage…
But around this time, along comes my brother. He takes one look at the boat and says, “Damn! That’s beautiful!” So I point out a flaw. He waves it off and says, “The only boat without scrapes and dents is in the showroom. This boat is going to sail!” Not to be dissuaded, I point out another flaw. He looks at me and says, “Will it float?”
My answer, “Yes.”
“OK then. Let’s get this thing in the water.”
And so we go back to work, and somehow it is OK. I stop worrying and focus on what remains to be done.
Sometimes someone visits the office. Someone I really respect and admire. I show them around and they say, “Wow, what a great team!” So I walk them over to the story board and point out that it’s out of date. They look at me and say, “That’s cool. Not many people even use physical dashboards.” I tell them that the team doesn’t use story points. They look at me and say, “Does the team deliver?”
My answer, “Yes.”
“OK then. Let’s sling some code.”
And so I’m reminded not to be such a damn perfectionist.
Love your boat.
Love your team.
Filed under: Agile, Coaching, Teams Tagged: perfection, Teams
An vielen Ecken hört man es: die “Generation Y” will anders arbeiten. Die jungen, gut ausgebildeten Menschen zwischen 20 und 30 wollen einfach nicht mehr so hart rackern wie die Generation vor ihnen, heißt es. Und andererseits wissen die Vertreter der “Generation Me” (auch als Baby Boomer bezeichnet) nicht, wie sie im Job mit dieser Generation umgehen sollen. Nähern wir uns dem Thema Work-Life-Balance mit der Brille der “Generation Me”, dann verfällt man schnell der Idee, dass es neben der Arbeit noch etwas anderes geben sollte. Neben der Arbeit. Mich hat diese Trennung von Arbeit und Freitzeit immer gewundert. So als hätte man zwei Leben, als könne man jede Minute zweimal ausgeben: privat und beruflich.Generation Me: erfolgreich krank
Woher kommt das Bedürfnis bei Menschen der Generation, der auch ich angehöre, nach dieser Work-Life-Balance? Vielleicht weil wir den Wohlstand, das zweite und das dritte Auto, damit erkauft haben. Wir haben sehr viel und sehr hart gearbeitet, denn harte Arbeit ist unser Statussymbol. Gleichzeitig haben wir nicht nur finanzielle Erfolge und Wohlstand erarbeitet: viele von uns haben sich im wahrsten Sinne des Wortes krank gearbeitet. Ich gebe es zu, auch ich bin bei zwei bis vier Flügen pro Woche und durch das ständige Schlafen in Hotels nicht so fit und gesund, wie ich es sein könnte. Auch die Zeitungen und Magazine sind voll von Berichten über unsere schwer erarbeiteten Zivilisationskrankheiten. Wäre ich, so wie viele andere, auch mit 30 Vater geworden, wäre meine Tochter oder mein Sohn jetzt schon 15 und würde sich zu Recht fragen, ob dieses Kaputtarbeiten irgendeinen Sinn hat und ob er oder sie das will. Ihre Antwort wäre natürlich: “Nein!” Und die Vertreter der Generation Y haben natürlich recht, sie müssen es auch gar nicht mehr.Langweilige Paradiese
Ihre Eltern haben in vielen Unternehmen bereits die vollkommenen Paradiese geschaffen. Dort sind die Arbeitszeiten festgezogen, alles ist geregelt und wer freiwillig mehr leisten will, wird schief angeschaut (natürlich gilt das nicht in jedem Unternehmen). Gleichzeitig wird die Alterspyramide die Gehälter steigen lassen. Bei einer momentanen Geburtenrate von 1,34 in Österreich und der Tatsache, dass die Baby Boomer allmählich in Massen in Rente gehen, wächst der Wert der Arbeitskraft ins Gigantische.
Gleichzeitig sind die großen Betriebe so durchgestylt, dass die Folge nur noch verwöhnte Langeweile sein kann. Wieso ich das sage?
Ein Beispiel: Ich hatte einen Bewerber zum Interviewtermin, der aus der Automobilwirtschaft kommt. Heute 30 Jahre alt, Doktor der Soziologie, entscheidet er sich bewusst gegen die 35-Stunden-Arbeitswoche in einem großen deutschen Automobilkonzern. Die Arbeit dort ist nicht etwa zu anstrengend, sondern zu langweilig. Dort sind die Arbeitsabläufe geklärt, die Projektmanager verbringen ihre Zeit in stundenlangen Meetings, in denen doch nichts Wesentliches passiert, und der Effekt, also ihr Beitrag, ist gleich Null. Die Arbeit wird in Großunternehmen bzw. -konzernen sowieso von Dienstleistern erledigt – wie es Putzerfische bei einem Wal tun. Etwas bewegen, Sinn stiften und sich beweisen, dabei vielleicht auch scheitern und lernen, ist in diesen Unternehmen schwer geworden.
Doch schauen wir mal dorthin, wo die eigentlichen Veränderungen derzeit passieren – nein, nicht bei Goolge und Co. Ganz ehrlich, eine Übermutter als Arbeitgeber, die mit ständig verfügbarem Essen, Massage und 1000 anderen Annehmlichkeiten aufwartet, wo Geld keine Rolle spielt und man machen kann, was man will, erzeugt kein Umfeld, in dem Innovation aufkommen kann. Der Spieltrieb wird angefacht, sicher, und es ist bestimmt ultracool, bei Google zu arbeiten. Aber mal ehrlich, welche Innovationen kamen von Google? Eine einzige! Ihre geniale Suche. Alles andere ist nachgebaut und bestenfalls optimiert. Google geht gerade den Weg der meisten großen Unternehmen: die Kreativität ist dahin, man beginnt, die Konkurrenz und die neuen Ideen zuzukaufen, statt selbst tolle Dinge zu machen.Neuer Realismus in der Arbeitswelt
Wo ist also das Neue für die Arbeitswelt? Es beginnt immer am Rand. Da ist etwas Neues zu beobachten. Wahrscheinlich werden jetzt viele Trendforscher sagen: “alter Kaffee”, aber ich nehme gerade etwas vollkommen Neues wahr. Kleine Firmen, die weltweit verteilt sind und dank neuer Kommunikations- und Arbeitsinfrastrukturen wie Google Hangout, Skype und GitHub Bedingungen geschaffen haben, mit denen man als kleines Team weltweit miteinander arbeiten kann, beginnen tatsächlich ganz anders zu arbeiten.
Da erzählen dann diese merkwürdigen Menschen aus der Generation Y, dass sie zuhause in ihren Wohnzimmern oder kleinen Arbeitszimmern sitzen, und gleichzeitig bei ihrer Familie sein können (Beispiele für diese Firmen sind: WordPress.com oder Bufferapp). Die Firmenmitglieder treffen sich ab und zu, um sich auch mal zu sehen, aber die Arbeit wird remote, verteilt und dezentralisiert gesteuert. Es entstehen dabei sogar neue Taskmanagement-Systeme, die tatsächlich ein neues Konzept verfolgen: IDoneThis. Sie zeigen, was gelungen ist, und nicht das, was man hätte tun sollen. Das ist eines der ersten Systeme, das mit einer vollkommen anderen Sicht entwickelt wurde. Hier ist es nicht vorgesehen, jemand anderem zu sagen, was er zu tun hat. Jeder sagt – offen – etwas darüber, was er getan hat. Ziemlich verrückt aus der Sicht der Generation ME. Work-Life-Balance spielt für die Generation Y keine Rolle mehr. Sie haben schon lange einen Weg gefunden, freier und viel realistischer mit ihrem Leben umzugehen.
It’s hard to drive digital initiatives and business transformation if you can’t create the business case. Stakeholder want to know what their investment is supposed to get them
One of the simplest ways to think about business cases is to think in terms of stakeholders, benefits, KPIs, costs, and risks over time frames.
While that’s the basic frame, there’s a bit of art and science when it comes to building effective business cases, especially when it involves transformational change.
Lucky for us, in the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in building better business cases for digital initiatives.
What I like about their guidance is that it matches my experienceLink Operational Changes to Tangible Business Benefits
The more you can link your roadmap to benefits that people care about and can measure, the better off you are.
Via Leading Digital:
“You need initiative-based business cases that establish a clear link from the operational changes in your roadmap to tangible business benefits. You will need to involve employees on the front lines to help validate how operational changes will contribute to strategic goals.”Work Out the Costs, the Benefits, and the Timing of Return
On a good note, the same building blocks that apply to any business case, apply to digital initiatives.
Via Leading Digital:
“The basic building blocks of a business case for digital initiatives are the same as for any business case. Your team needs to work out the costs, the benefits, and the timing of the return. But digital transformation is still uncharted territory. The cost side of the equation is easier, but benefits can be difficult to quantify, even when, intuitively, they seem crystal clear.”Start with What You Know
Building a business case is an art and a science. To avoid getting lost in analysis paralysis, start with what you know.
Via Leading Digital:
“Building a business case for digital initiatives is both an art an a science. With so many unknowns, you'll need to take a pragmatic approach to investments in light of what you know and what you don't know.
Start with what you know, where you have most of the information you need to support a robust cost-benefit analysis. A few lessons learned from our Digital Masters can be useful.”Don’t Build Your Business Case as a Series of Technology Investments
If you only consider the technology part of the story, you’ll miss the bigger picture. Digital initiatives involves organizational change management as well as process change. A digital initiative is really a change in terms of people, process, and technology, and adoption is a big deal.
Via Leading Digital:
“Don't build your business case as a series of technology investments. You will miss a big part of the costs. Cost the adoption efforts--digital skill building, organizational change, communication, and training--as well as the deployment of the technology. You won't realize the full benefits--or possibly any benefits--without them.”Frame the Benefits in Terms of Business Outcomes
If you don’t work backwards from the end-in-mind, you might not get there. You need clarity on the business outcomes so that you can chunk up the right path to get there, while flowing continuous value along the way.
Via Leading Digital:
“Frame the benefits in terms of the business outcomes you want to reach. These outcomes can be the achievement of goals or the fixing of problems--that is, outcomes that drive more customer value, higher revenue, or a better cost position. Then define the tangible business impact and work backward into the levers and metrics that will indicate what 'good' looks like. For instance, if one of your investments is supposed to increase digital customer engagement, your outcome might be increasing engagement-to-sales conversation. Then work back into the main metrics that drive this outcome, for example, visits, like inquiries, ratings, reorders, and the like.
When the business impact5 of an initiative is not totally clear, look at companies that have already made similar investments. Your technology vendors can also be a rich, if somewhat biased, source of business cases for some digital investments.”Run Small Pilots, Evaluate Results, and Refine Your Approach
To reduce risk, start with pilots to live and learn. This will help you make informed decisions as part of your business case development.
Via Leading Digital:
“But, whatever you do, some digital investment cases will be trickier to justify, be they investments in emerging technologies or cutting-edge practices. For example, what is the value of gamifying your brand's social communities? For these types of investment opportunities, experiment with a test-and-learn approach. State your measures of success, run small pilots, evaluate results, and refine your approach. Several useful tools and methods exist, such as hypothesis-driven experiments with control groups, or A/B testing. The successes (and failures) of small experiments can then become the benefits rationale to invest at greater scale. Whatever the method, use an analytical approach; the quality of your estimated return depends on it.
Translating your vision into strategic goals and building an actionable roadmap is the firs step in focusing your investment. It will galvanize the organization into action. But if you needed to be an architect to develop your vision, you need to be a plumber to develop your roadmap. Be prepared to get your hands dirty.”
While practice makes perfect, business cases aren’t about perfect. Their job is to help you get the right investment from stakeholders so you can work on the right things, at the right time, to make the right impact.You Might Also Like
Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.
We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.
I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.
The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM. The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning. ROAM stands for Resolved, Owned, Accepted, Mitigated. The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them. These risks are then place on a visible grid that has each of the four categories marked. In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning. Cool!Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
We have already had User Story as most popular tool. But this is not the end. Today about Iterations: the small and big ones, these that are completed and those that are never stopped.
Iteration is a period of 1 to 4 weeks. During this time Customer needs to decide what is the most important at this moment. 4 weeks is also called the Sprint but we prefer Iteration as it’s stronger option.
Iteration is not only about programming but also about tests and more. Actually tests are run before the programming phase.
We also have to mention about infinite period. In this case Iteration is one, only User Story has to be completed in some period of time and then disappears. In this place another User Story appears. Customer tells about that User Story and if it’s good we start with the new one.
And what do you think about this?
Coaching can make the difference between an organisation’s success or failure. In this month’s blog, Peter Hundermark outlines why effective coaching allows companies to admit their weaknesses and move towards a happier and more effective workplace. Read the full article here.Kanban Training We have FOUR seats remaining on the upcoming Applying Kanban (Foundation) course taking place on the 20-21 Oct 2014 in Sandton. Be sure to book your place before these are snapped up. Should these dates not work for you, we will be running the course again on the 04-05 May 2015.
We also still have a few spaces available on our upcoming Improving & Scaling Kanban (Advanced) course which will be taking place in Sandton on the 23-24 Oct 2014. We are running a 3-for-2 special offer on both the certified Foundation and Advanced courses, so be sure to secure your place!
InfoQ have published the remaining two articles in the series from the short book “Leading Self-Organising Teams” written by Dr. Sigi Kaltenecker & Peter Hundermark. Have a read of these articles: “why do we need self-organising teams?” and “what is Leading Self-Organising Teams all about?”
Q&A TeleconferencesEsther Derby is offering free Q&A teleconferencing sessions. Each month Esther chooses a topic which will be of interest to people who coach, manage, or work on software teams. Follow this link to sign up. Upcoming Courses Applying Kanban (Foundation) – (JHB) – Only 4 seats left!
20-21 Oct 2014
FNB Conference & Learning Centre, Sandton
Improving & Scaling Kanban (Advanced) – (JHB)
23-24 Oct 2014
FNB Conference & Learning Centre, Sandton
Certified Scrum Product Owner (JHB) – Fully booked!
04 – 05 Nov 2014
FNB Conference & Learning Centre, Sandton
Certified Scrum Master (JHB)
01-02 Dec 2014
FNB Conference & Learning Centre, Sandton
Course schedule and Book Online
I’m a little down on the notion of continuous improvement these days. It’s not that it doesn’t happen – it does…sometimes. I simply fear that it promises too much. I think part of it is the terminology. You see in the real world continuous improvement is neither truly continuous or necessarily an improvement.
To begin with, I’ve critiqued the notion of continuously improving before from the point of view that keeping any process happening full time is ludicrous. Certainly once every sprint is nowhere near continuous. I guess maybe it is continuous when you compare it to other more plan driven methods, but that’s far from continuous in my book.
No, the part that I find most objectionable is the improving part. You see, it’s misleading. It suggests to me that every change is an improvement. That every effort is a step forward, not back. And that is simply not how it works. It would be better labelled periodic experimentation, or punctuated mutation. You see, in the real world, when we change something, we never really know if it’s going to work out or not. There are 50/50 odds that the change will actually make things worse!
Of course that’s a good thing. We learn a little either way. Hopefully.
The problem I have with continuous improvement is that it sets up an unreasonable expectation in those we sell it to. To restate the sales pitch: every change will be an improvement and they happen all the time.
If every change were really an improvement, I would be worried that I had been transported to an alternative universe. That I was being monitored by aliens. That there was a black helicopter hovering over my house. I’d be making a tin foil bunny suit. Fortunately I know what universe I’m in, that there aren’t any black helicopters over my house, and tin foil tends to chafe in the damnedest places. Not too sure about the aliens…
Fortunately, many of my efforts at improvement fail. And that’s the way it should be.
Filed under: Agile, Process Tagged: continuous, evolution, experimentation, failure, improvement
We’ve been working diligently on continued conceptualization of the SAFe LSE Big Picture, as well as the new article content. To that end, we’ve just updated the Big Picture to rev 0.30. (yeah, 30 revs so far, see below).
In addition, we just announced the first training course for SAFe LSE. Leading SAFe LSE is a three-day course, the first of which which will be offered in Boulder, February 3-5, 2015. Registration is now open here. Harry Koehnemann, Alex Yakyma and I will be teaching that course, so you can hear the new content “right from the horses” mouths.
With respect to the new framework, our current target is to publish the website as a work-in-process towards the end of this year (likely end of November), with a full release, including an exam and Certification process, later in 2015.
For people in 20th century organisations training was an obvious necessity. Just look at the still-classical organisation and see that it has a Training Department neatly tucked into the organisation chart just under Human Resources. (I hate that name…but I digress.)
Much changes in our post-industrial world where we think for a living, solving increasingly complex problems. Our paradigm for helping people be effective has not yet caught up.
What are the challenges?
- We are solving hard problems. This requires the brains of multiple people to be aligned and work collectively to emerge solution options.
- Failure remains stigmatised as something bad, rather than being recognised as an essential and desirable outcome of experimentation towards innovation.
- We remain stuck in authoritative command-and-control cultures that fail to unlock the potential of people.
- Employees acknowledge their own individual achievements, but less so their contribution to the result of a shared effort.
- Managers have not yet grasped their new role as enablers rather than directors.
- Most organisations reward individualism while hoping for teamwork.
- …add yours here…
Professional coaching may be described as a method for helping a person or a team to achieve specific goals in their professional lives. Paraphrasing Kaltenecker and Myllerup: the coach acknowledges that the person or team being coached already has the potential abilities required for reaching the goals and the assignment for the coach is to help unlock this hidden potential.
An “agile coach” often steps into acting as a teacher, advisor, mentor or role model. Here she applies her own expertise to lead and guide the individual or team in specific ways. Yet as soon as possible she should return to a coaching stance to return appropriate the power balance to the relationship.
The diagram depicts the difference between when the “agile” coach is relying on her own expertise of the content as distinct from the systemic coach using her own ignorance of the full organisational context and applying curiosity as a powerful helping tool to build relationship.
Ask any successful leader and she will tell you stories about the people who have helped her, formally and informally, along her journey.
In order to learn and grow we require honest feedback. Without enough trust, honest feedback is unlikely to be offered and received in a productive manner. Traditional work environments do not provide safety for trust to flourish.
And in the modern work context that requires collaboration to produce good results we need to develop new “soft” skills that we were not taught at university or technicon. Teams and individuals need to learn to be vulnerable to one another.
However it is not a given that we will ask for help. There are hard questions to answer, for example:
- How do I recognise when I or my team needs help? Am I even capable of knowing what it is I don’t know (my blind spots)?
- Why would my boss pay me a salary when I need outside help to do my job?
- How does asking for help make me feel? I have to “lose face” to accept help from another.
- …add your own…
In the South African cultural context where “cowboys don’t cry” and “boer maak ’n plan” it can be particularly hard to ask for help. And in the “controlling” and “competitive” styles of organisational cultures that still predominate worldwide it can be seen as a sign of weakness.
So many of us live with an unhealthy tension between needing help from others in order to grow, and the uncertainty about whether or when it’s okay to ask.
The coach as trusted external party is well-skilled and well-placed to facilitate the necessary conversations to help teams grow trust, deal with conflict and offer commitment that in turn lead to increased accountability and improved outcomes.An Economic View
In work over nine years with more than 100 teams we have observed a marked difference between the extent and the pace of growth of individuals and teams that have received coaching and those who have “gone it alone” after, perhaps, a two-day training class.
An analysis of our own data shows a correlation between “performing” teams and the quantum of help. The sweet spot seems to be between one and two days of coaching per team member during the first year of transition. To be clear this includes all facets such as advising and organisational development. Our data does differentiate between individual and team coaching, yet clearly there is a need for both.
Benefits we have observed during and after coaching include:
- Happier and more engaged team members
- Reduced staff turnover
- An increased sense of “we”
- An increase in self-confidence and independence
- Increases customer and stakeholder satisfaction through value delivery
- Increased throughput and decreased “time to market”
- Increased transparency and predictability
When asked how soon the benefits exceeded the costs, many clients have experienced improvement within a few weeks and the classic “J-curve” of change has not been felt. And it is not uncommon to hear “we have doubled/halved X compared with last quarter/year”.Adding Perspective
Before we conclude that coaching is some “magic elixir”, let’s be clear that contexts differ and it is hard to attribute causality to a single element. Nevertheless we have many times heard “we should have got coaching earlier and had more of it”.
As Weick and Sutcliffe remind us in their excellent book about High Reliability Organisations, it is “a sign of strength to know when you’ve reached the limits of your knowledge and know enough to ask for help”.
¹Sigi Kaltenecker (Loop Organisationsberatung) & Bent Myllerup (agile42): Agile & Systemic Coaching
²Karl Weick and Kathleen Sutcliffe: Managing the Unexpected—Resilient Performance in an Age of Uncertainty (Second Edition, 2007, Wiley), page 80.
Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them. This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent. Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.
I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization. It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile. It is about urgency and need, and about a recognition that Agile is better than not-Agile. If you aren’t in that situation, this is not the book list for you.
These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture. Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.
This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments. These books all touch on culture in various ways, and build on the ideas in the books about culture. For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.
Agile at Scale
These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.
These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.
The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.
The OpenAgile Primer – Mishkin Berteig, et. al.
Priming Kanban – Jesper BoegTry out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
In Part 1 of this four-part blog series, I explained why a cookie-cutter approach will not work as you undertake large-scale agile initiatives. Each agile project has a unique context: assumptions, situation, team members and their skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc. In Part 1, I proposed a fairly comprehensive list of 25 scaling agile parameters classified into six scaling aspects: Teams, Customers/Users, Agile Methods and Environments, Product/Solution, Complexity, and Value Chain (Tables 1-4 of Part 1). I also presented a brief overview of various popular agile and lean scaling frameworks: Scaled Agile Framework® (SAFe™), LeSS, DAD and MAXOS.
Although there are differences among SAFe, LeSS and DAD, they all are very different from MAXOS. SAFe and MAXOS represent radically different approaches to scaling agile. In Part 2, I compared and contrasted SAFe vs. MAXOS in depth. Tables 5-10 of Part 2 presented the differences between SAFe and MAXOS from the perspective of 25 scaling agile parameters covered in Tables 1-4 of Part 1.
In Part 3, I presented the Sweet Spots, Challenge Zones and Unfit zones for SAFe and MAXOS. Figure 1 in Part 3 illustrated the Sweet Spot, Challenge Zone and Unfit Zone for SAFe, while Figure 2 presented similar information for MAXOS. The Sweet spot indicates a good match between a scaling agile framework and all scaling agile parameters; consequently the implementation becomes easier, more efficient and effective. The Challenge Zone indicates a challenging match between a framework and one or more scaling agile parameters, and requires more implementation effort compared to the Sweet Spot. The Unfit Zone indicates a very poor (almost unworkable) match between a framework and one or more scaling agile parameters.
In Part 3, I explained why it is a good idea to get as close as possible to the sweet spot of your chosen scaling agile framework; it increases the likelihood that your pilot large-scale agile project will have fewer difficulties in succeeding. If you find that your large-scale agile initiative (a program or a portfolio) is in the Unfit or Challenge Zone, you need to find the reason(s). The root cause is likely to be one of these two things:
1. Internal to your own organization (its history, culture, current practices, etc.). This is an opportunity for your senior management to remove or mitigate those reasons and demonstrate their understanding and commitment to the success of scaling agile.
2. Arising from the market and business environment of your organization. These pressures cannot be removed by senior management (if you want to stay in the business). You will need to replace or augment some of the scaling agile framework practices with your own custom practices, while retaining the practices from the framework that are still applicable.
The journey from Unfit or Challenge Zone to Sweet Spot is uniquely yours, and cannot be copied from a cookbook. Over time, you will find that you are moving closer and closer to the Sweet Spot, but may still have a few areas in the Challenge Zone to address.
In this final part of my series, I explain a very important challenge for Scaling Agile Your Way. It requires each team, program or portfolio to implement one or more key aspects of the chosen framework (whether the key aspect is in the Sweet Spot or Challenge Zone) in unique and customized ways. I explain how the Scrum at Scale (meta)-framework under development by Jeff Sutherland and Alex Brown can be applied to SAFe to make it less prescriptive, “modularize” SAFe, and allow customized implementation of those modules.
The Scrum at Scale framework provides a general language for talking about how to scale Scrum. At its roots, Scrum is an object-oriented framework. Each role, artifact and ceremony is defined by the teams’ objectives, participants, inputs and outputs. Core Scrum allows for many different ways to achieve objectives within given input/output constraints. Modularity allows organizations to establish and improve agile practices incrementally by focusing on one independent module at a time. Scrum at Scale aspires to develop a “pattern library” of successful approaches that can be used in different contexts; this pattern library is being developed based on a crowd-sourcing approach.
Tables 12-16 in this post (see below) present 10 modules of the Scrum at Scale framework:
1. Team-Level Scrum Process
2. Strategic Vision
3. Backlog Prioritization
4. Backlog Decomposition and Refinement
5. Release Planning
6. Release Management
8. Continuous Improvement and Impediment Removal
9. Cross-Team Coordination
10. Metrics and Transparency
As the Scrum framework is object-oriented, each of these 10 modules has a set of well-defined goals, inputs and outputs. It is up to each entity (team or business unit or organization) to implement each module in a way that best suits its own needs and constraints, so long as it produces the desired goals and outputs from a given set of inputs. The details of implementing each module should be left to each entity, as the implementation details are expected to be different. Each of Tables 12-16 presents two modules and explains how object-oriented implementation of each module is applicable to SAFe.
SAFe is characterized by its critics as too prescriptive; some of this critique may be fair while other is not. Critics allege that because SAFe is (overly) prescriptive, it may not work well in many situations. This prescriptive orientation (real or perceived) of SAFe can be reduced considerably by taking a strong, object-oriented approach in modularizing and implementing SAFe. Instead of prescribing or specifying how different goals or ceremonies of SAFe should be implemented, why not follow the object-oriented approach of Scrum at Scale framework while implementing SAFe — where each module’s goals, outputs and inputs are emphasized while leaving the implementation details to each entity (team or program or portfolio)? Of course, constraints arising from inter-team or inter-program coordination and synchronization must be met; even those constraints should be specified in terms of their goals — not by prescribing their implementation details (think of “object-oriented” constraints).
Table 12: Modules 1 and 2 of Scrum at Scale (Meta)-Framework
and its Application to SAFe
Table 13: Modules 3 and 4 of Scrum at Scale (Meta)-Framework
and its Application to SAFe
Table 14: Modules 5 and 6 of Scrum at Scale (Meta)-Framework
and its Application to SAFe
Table 15: Modules 7 and 8 of Scrum at Scale (Meta)-Framework
and its Application to SAFe
Table 16: Modules 9 and 10 of Scrum at Scale (Meta)-Framework
and its Application to SAFe
These will arise mostly in the context of implementing its advanced engineering practices of:
- Code contribution
- Automated testing
- Continuous integration
- Feature switches
- Continuous delivery
- Collecting and analyzing automated user feedback
- Making use of cloud computing facilities on a massive scale, etc.
There are open-source and some commercial products available for automated testing, continuous integration and using cloud computing facilities for software development, testing and deployment. I will not elaborate on MAXOS customization here.
How may an object-oriented implementation of SAFe (applying Scrum at Scale meta-framework guidelines, as explained in this part) suit your organization’s needs and constraints better than following SAFe “by the book?” Besides the aspects of customization covered in Tables 12-16, are there any other aspects that come to your mind? I would love to hear from you on these questions or any aspect of this four-part blog series, either here, by email (Satish.Thatte@VersionOne.com), or on
Part 1: Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly
Part 2: Scaling Agile Your Way: SAFe™ vs. MAXOS
Part 3: Scaling Agile Your Way: Sweet Spots, Challenge and Unfit Zones for SAFe and MAXOS