Great new video about Kanban by Michael Badali. This is the third video in a regular series:
Another short video for your viewing pleasure! Kanban in One Minute – Do It Right by Michael Badali.
Check out our first video “Kanban Basics”.
Michael Badali is a Kanban expert with years of experience in Kanban and other Agile methods including nearly 2 years working as an internal coach at HP in China and the UK.
Thanks everyone for feedback, comments and suggestions for my new book, Agile Advice – Creating High Performance Teams In Business Organizations. It is available for purchase (only $2.99) on lulu.com (that’s where the link goes). Here is the blurb about the book:
Agile Advice is a collection of brief articles and longer essays about Agile methods and their principles and practices. Agile Advice articles come primarily from the popular AgileAdvice.com blog which has been in the top 50 of Agile blogs since its inception in 2005. The book has three never-before-seen essays including “Agile Mining at a Large Canadian Oil Sands Company”, “Crossing the Knowing-Doing Gap”, and “Becoming a Professional Software Developer”. Agile Advice also has a whole section on choosing an Agile method. The author, Mishkin Berteig, has been working with Agile methods such as Scrum, Kanban, and Extreme Programming since 1996.
Once you have read it, I would love to hear your feedback and reviews here. I will try to publish updates quarterly over the next year to make it even better! Thanks again for your support.
Two nights ago I had a great discussion with my son, Justice Berteig, about how we have been managing to do house cleaning every week. We have been using a very basic Kanban system. I have created about 100 stickies each of which has a basic cleaning task such as “tidy the kitchen counters” or “vacuum the office floor” or “clean the powder room toilet”. If we do all of the tasks, it represents a fairly complete cleaning of the whole house. Every Saturday morning, all six of us (myself, my wife and our four kids) choose one task at a time and put the sticky for that task in the “In Progress” column. When we finish a task, we move it to the “Done” column. When all the tasks are done, we all are finished. We reuse the stickies each week. Sometimes if we want to do a quick clean, we won’t put out all of the stickies.
It works well in one specific way: everything gets done!
But Justice was complaining about the system because he works a lot harder and one of my younger kids has admitted to doing less than she could… because she can get away with it with this system.
Last week we tried a modified system where each person has a task allocation. For example, Justice had an allocation of 25 tasks. Our younger daughter had an allocation of just 5 tasks. We then took turns to choose one task at a time (although there were a lot of exceptions to this) until all the tasks are pre-allocated (similar to how teams used to do Sprint Planning). But, although some people finished all their tasks, not everyone did and so there were a number of things left over that never got finished.
In other words, we stopped using a Kanban system, and we stopped reaching the overall goal of a clean house.
So Justice and I had a long conversation about this problem. In the interests of continuous improvement and experimentation, I didn’t just force the issue back to the old Kanban system. Instead we decided to try the following changes:
- Limit the tasks to only those in common areas. Private areas such as bedrooms would be taken off the master list.
- Each task would get an estimate from a scale of 1 to 3 to represent their relative difficulty. We will talk as a family about the estimates and maybe use a simplified “bucket system“.
- Now, instead of an allocation of a specific number of tasks, the allocation would be for a total amount of effort. We agreed that our youngest would get a smaller allocation still, but she could take any number of tasks to fill it up.
- We also agreed to be more disciplined about taking turns to choose tasks.
I’m going to add one more thing which is to do a specific retrospective on how it worked to see if we can come up with further improvements. I have to admit that I hope we go back to the Kanban approach!!!
Check out our new Kanban training offering: Kanban: Gentle Change currently available for public enrolment in the Toronto area and for in-house delivery wherever you might be!
New Agile Certification Training
Our new premium offering: the Certified Real Agility Coach course is delivered in an unusual format of 40 days (yes, forty) spread over one year. This in-depth, advanced training program is designed to help people with experience on Agile teams to become fully-capable independent Agile coaches. Worried about the time commitment? A substantial portion of the course is delivered as on-the-job training and a significant number of course hours are outside regular working hours… and the schedule is flexible to accommodate participants’ unique scheduling needs. Spots are extremely limited for this course. Reserve your spot now! (Contributes all the training hours required for the Certified Scrum Professional designation. As well, if you do not already have the CSM and CSPO designations, you will receive free enrolment in either or both of those courses once your registration has been confirmed.)
Since Travis Birch and Mishkin Berteig have become Certified SAFE Program Consultants, we are now offering the Leading Safe 2-day course for project, program and functional managers, change agents and department leaders. Learn about the Scaled Agile Framework; one the most popular enterprise Agile frameworks. SAFe combines Scrum, Extreme Programming and Lean to effectively allow larger groups of people to execute programs while interfacing effectively with traditional corporate governance. Do you have 25 people or more working on a program? Then the Leading SAFe training is for you!
New Agile Introduction Courses
Scrum and Enterprise Agile for Executives is a half-day workshop designed to help you solve one of the biggest problems organizations have: how to become more Agile? Using the tools and techniques of the Real Agility Program, participants will be guided to make effective long- and short-term plans for increasing productivity, innovation, quality and customer satisfaction. This workshop is delivered by Mishkin Berteig who has helped numerous executives at organizations large and small with successful Agile transformations. Just $250 per person!
Travis Birch, a Partner at Berteig Consulting who has years of experience helping Agile teams reach award-winning levels of performance, is going to be delivering two of our new offerings:
Choosing an Agile Career is a one-day workshop designed to help people who don’t yet know how they can best fit into the most important revolution sweeping the corporate world. Should you be a ScrumMaster? A Product Owner? An Agile Coach? Something else? Ideal for people who have been asked by their executives to sort out their career path in a newly Agile organization or department. $450/person with an early-bird discount available for some dates.
Kanban: Gentle Change is a deep-dive immersion into a critical process-improvement and teamwork technique Learn how tools for making work visible can improve productivity, throughput and efficiency.. Ideally suited for team leads, project and functional managers, HR managers and process improvement managers. $450/person with an early-bird discount available for some dates. Counts as 7 PDUs with the PMI and contributes to the Agile Certified Practitioner designation.
Of course, we continue to offer our extremely well-received (often sold out!) Certified ScrumMaster and Certified Scrum Product Owner training courses. These courses are immersive, intensive, and designed to help you to become great ScrumMasters and Product Owners.
Please see our complete 2015 Agile and Scrum course schedule here! Most of our courses are held in the Toronto area which has a great international airport, fantastic food, amazing entertainment, and is just generally a fun place to come for a bit of training and a bit of sight-seeing. Some courses are also offered in other cities including Vancouver, London Ontario, and Waterloo. Most of our courses are also available for in-house private dates. Please contact email@example.com for more information about group discounts, corporate savings programs or in-house private offerings.
COMING SOON We are working to offer Certified Scrum Developer (CSD) training as a complement to our already successful Certified ScrumMaster and Certified Scrum Product Owner training courses. The CSD course will help technology professionals learn the critical Agile engineering and teamwork practices that are absolutely required to make Scrum successful in delivering software products. This training is highly technical and participants are expected to already be strong software developers.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
- How Two Hours Can Waste Two Weeks (75,000+ visits)
- The Seven Core Practices of Agile Work (25,000+ visits)
- Eight Barriers to Effective Listening (17,000+ visits)
- Seven Essential Teamwork Skills (17,000+ visits)
- 24 Common Scrum Pitfalls Summarized (15,000+ visits)
- Mentoring and Coaching: What is the Difference? (14,000+ visits)
- Wideband Delphi Estimation Technique (14,000+ visits)
- The Pros and Cons of Short Iterations (13,000+ visits)
- Three Concepts of Value Stream Mapping (13,000+ visits)
- Agile Work and the PMBoK Definition of Project (11,000+ visits)
Ten Most Commented Upon Agile Advice Articles
- 24 Common Scrum Pitfalls Summarized (19 comments)
- Agile Becomes Easier with Useful Tools (12 comments)
- Important Words about Scrum and Tools (9 comments)
- The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
- The Definition of Done is Badly Named (8 comments)
- How Two Hours Can Waste Two Weeks (7 comments)
- Agile is Not Communism (7 comments)
- Agile Tools vs. Agile Books (6 comments)
- The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
- The Planning Game: an Estimation Method for Agile Teams (5 comments)
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
- Paul Heidema (34 articles)
- Travis Birch (24 articles)
- Christian Gruber (19 articles)
- Mike Caspar (16 articles)
- Shabnam Tashakour (13 articles)
Plans for the Future – Five Top Ideas for Series
- Essays on each of the Values and Principles of the Agile Manifesto
- Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
- Real Agility Program case studies
- Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
- New guest articles from thought and practice leaders.
Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
Read “Fearless Change”
I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.
Don’t Call it “Agile”
This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.
A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.
Get Some Training
Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.
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 Boeg
Well, last spring I announced that I was going to be publishing a collection of the best Agile Advice articles in a book. I managed to get an ISBN number, got a great cover page design, and so it is almost done. I’m still trying to figure out how to build an index… any suggestions would be welcome!!! But… I’m hoping to get it published on iBooks and Amazon in the next month or two. Let me know if you have any feedback on “must-have” Agile Advice articles – there’s still time to add / edit the contents.
There are six major sections to the book:
- Basics and Foundations
- Applications and Variations
- Agile and Other Systems
- For Managers and Executives
- Bonus Chapters
- Agile Methods Quick Reference and Selection Guide
The book will also have a small collection of 3 in-depth articles that have never been published here on Agile Advice (and never will be). The three special articles are:
- Agile Mining at a Large Canadian Oil Sands Company
- Crossing the Knowing-Doing Gap
- Becoming a Professional Software Developer
Again, any feedback on tools or techniques for creating a quick index section on a book would be great. I’m using LibreOffice for my word processor on a Mac. I’m cool with command-line tools if there’s something good!
When I am speaking with executives, ScrumMasters and other leaders of change in organizations, I often present a simple 3-layer model to understand the relationship between the various moving parts in the Agile Framework:
- The Agile Values and Principles – These describe the culture and, in the Agile Manifesto, are the definition of the word “Agile” as applied to software development. I didn’t write the Agile Manifesto so I don’t get to re-define the word Agile. To give an example: in the manifesto it says “The best architectures, requirements and designs emerge out of self-organizing teams.” As a former enterprise architect at Charles Schwab, I struggled with what I saw as incredibly wasteful up-front architectural activities when I knew that developers would (sometimes) ignore my glorious ivory-tower plans! Therefore, if you are still doing up-front architecture and forcing your teams to comply to that architecture, you aren’t Agile. Therefore, as an individual, a team or an organization, you need to make a conscious decision to “BE” Agile or not… and if you decide not, then please don’t call yourselves Agile.
- The Agile Toolkit – There are many hundreds of distinct tools in the Agile toolkit including Scrum, OpenAgile and other “large” Agile methods, as well as the Planning Game, Product Box, Test-Driven Development and other “small” Agile techniques. Any group of people trying to BE Agile, will need to use dozens or even hundreds of different Agile tools. I call them tools because the analogy with construction tools is a very good one. Scrum is like a hammer. But you can’t do much with just a hammer. Scrum is a great, simple tool. But you always need other tools as well to actually get stuff done. All the tools in the Agile Toolkit are compatible with the Agile Values and Principles. Even so, it is possible to use the Agile Tools without being Agile. A Scrum team that never gets together face-to-face is not an Agile team: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” (Video conferencing doesn’t count.)
- The Agile Organization – When you start using a tool, there is a learning period. We start by being conscious of our incompetence and as we persist, we become competent… but it isn’t natural or habitual yet. Eventually, with continued use, we become unconscious of the tool. IDE’s and version control are like this in most organizations: we don’t even think about them! But getting through that initial stage requires us to change; to develop new skills. This process usually requires discomfort or pain (including psychological pain). An organization attempting to BE Agile and to use many of the tools in the Agile Toolkit will need to make many changes and often these will be difficult. For example, incorporating the Product Owner role from Scrum into your organization requires new role definitions, new performance evaluation practices and criteria, new compensation systems, new communication and reporting mechanisms, new authority and accountability processes, etc. etc. All of the changes required are about creating Enterprise Agility throughout the whole organization, beyond just software or IT. These extensive changes are often started in a very ad hoc manner, but at some point they need to become systematic. This is an important decision point for executive management: are we going to be Pragmatic about our Enterprise Agile adoption, or are we going to be Transformative about our Enterprise Agile adoption.
All of this is summarized in this graphic:
The Agile Framework [PDF]
I sometimes also call this the “Agile Ecosystem” since it is a constantly evolving set of ideas (processes, tools, resources) that does not have a clearly defined boundary. For example, the technique of Value Stream Mapping comes from Lean manufacturing but has also be broadly adopted by Agile practitioners.
This is “my” blog – I write most of the articles, and it is owned by the business in which I am a major partner. I recently was reviewing comments in the moderation queue and came across this “gem”:
This man is a scammer, agile snake oil only 600, what a bargain. Filthy scamming piece of crap, he’s probably stupid enough to believe his own s**t too.
I’m assuming this person, who is anonymous, is upset either about something I said here on this blog, or possibly something that I (or one of my colleagues) did while we were working with one of our clients.
Several months ago, I was also made aware of a posting about Berteig Consulting (and myself) on Ripoff Report. I’m not going to link to it, but I will quote it here:
Our company undergoes Agile transformation. Our management decided to hire Berteig Consulting
– a bunch of charlatans spending hours talking absolute nonsense.
They promise sky rocketing performance because they teach us to ( than follows a great number of words with no meaning). We must reflect in Buddish manner, talk to each other, discuss obstacles, be truthful, play stupid games,…. They charge company big money for waisting employees time for endless meetings and providing us with useless information.
Honestly, these sorts of comments make me a bit sad, a bit down. But here’s what I think about them.
The Agile “Scam”
Let’s make sure we know what we are talking about. Agile is defined in the the Agile Manifesto. If you aren’t familiar with it, please take a look. Basically, the purpose of Agile is to find better ways of building software that are based in practice. In other words, by people actually building software, and sharing their knowledge, experience and the values and principles that helped them do what they did.
The thing about values and principles is that they are a bit like axioms in formal logic: you can’t prove them. They are a starting point. So, if you read the Agile Manifesto and you happen to think that
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
is “Buddish” (whatever that is, presumably Buddhist), and that being “Buddish” is bad or useless, then that is certainly your right. I can’t prove that this principle of the Agile Menifesto is “right” or “correct” or “always the best thing evar.” But I like it. I think it’s good. I believe in it. So I guess I am stupid enough to believe my own s**t. Except that it’s not my own. I didn’t write the Agile Manifesto. But I do fully support it. And, without exception, I think that if work environments tried to put in place the values and principles of the Agile Manifesto, the world would be a (slightly) better place.
So is it a scam? Well, if it is, I’m being scammed too. I work crazy long hours, and although I make a decent living, I’m certainly not getting rich off this Agile thing. When I think of a scam, I think of “get rich quick” or “lose 20 pounds in 20 days” or those sorts of things that promise unbelievable results with little or no effort.
Unfortunately, Agile isn’t like that. Here is how I think of three Agile methods:
- Scrum: incredible results at the cost of incredible pain. This is kind of like I imagine detox. An organization is near death and needs to be revived so extreme measures (Scrum) have to be taken. Requires significant outside help.
- OpenAgile: good medium-term results that require significant investment. This is kind of like making a conscious change from a poor diet with lots of junk food to a good diet: takes discipline, but do-able with good encouragement and support.
- Kanban: modest long-term results with relatively low effort. This is like deciding to change only one thing about your health at a time even if you have lots of health problems. Lots of small wins accumulate over time. Doesn’t require much outside help.
Of course, my descriptions of these are _vast_ simplifications for the purposes of discussing the Agile “scam”. Do professional sports teams or Olympic athletes need coaches? Probably most people would agree they do need that outside help. Is coaching sports teams or athletes a “scam”? Nope. Not all coaches are good, certainly, but coaching is an essential (sometimes difficult) investment to get to that level of high performance.
Of course, not all Agile transformations or adoptions are good. The Agile Manifesto is not easy for most people, teams or organizations to truly embrace. One of the most common problems I see is that an organization believes that it can have distributed or remote team members and somehow have effective communication among those team members. This is just one simple example that comes directly from the Agile Manifesto:
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
I guess, technically, the Agile Manifesto doesn’t out-and-out say that a team must be co-located, but boy-oh-boy does it ever make a difference.
And yet, doing radical collocation is damn hard for most organizations. So lots of organizations try to adopt Agile techniques without collocation. And, mostly, their results suck. Or they try to do collocation, but totally botch it.
Any given principle or value of the Agile Manifesto has its own challenges. And so most Agile implementations are distant echoes of the incredible results that some rare organizations achieve when they really get Agile.
My Track Record
As a consultant, coach and trainer, I sometimes wish that I could say that I have never failed, that I have never given bad advice. That’s because in complex human systems, it is very very very hard to sort out cause and effect relationships. If one of my clients fails to have a dramatic transformation is it because:
- I gave bad advice?
- Someone at the client subverted the transformation effort?
- An executive didn’t support it enough?
- Market forces destabilized the transformation?
- The organization’s culture treated Agile as an invasion and fought it off?
- Agile just wasn’t “right” for the organization?
- Agile wasn’t adopted soon enough?
On the other hand, I couldn’t very well be a coach, consultant or trainer if I didn’t have a clue. My colleagues, Paul and Travis (who are named in the Ripoff Reports article), and others whom I have worked with (Nica, David, Mike, Deborah, Christian, another Mike, Allistair, Holleh, yet another Mike,a Michael, and another Michael (wow!), Garry, Jim, Mark, Mary, Sanjiv, yes even another Michael, Julien, Brenda, Derek…) are all smart, experienced, sincere, helpful people… who all know what it takes to produce good results.
The “Secret” Essence of Successful Agile
And, strangely, the essence of it is encapsulated in just a few basic basics:
Truthfulness (vs. hypocrisy, lies and deception)
Collaboration (vs. competition or individualism)
Service to Others (vs. greed and apathy)
and, ultimately, love between people.
So. To those two people who felt they needed to spew out their hatred, their pain, or whatever it is that they are suffering from, I encourage you to contact me directly. My email address and phone number are public. I can’t promise to solve your problem, but I will give you love and whatever help I can extend.
We have already written about how Leadership and Delivery Teams operate in a Real Agility Program. It’s time to look at our Recommendations component: getting started on the right path for Real Agility.
Recommendations = Assessment + Playbook
In the assessment portion of the Recommendations component, we gather information about the current situation at an organization. This includes everything from detailed practices, processes and tools, to strategies and organizational culture. This assessment work is designed to help everyone understand the organization’s current gaps, and what strengths it has that will best support it to cross those gaps to Real Agility. The Assessment includes an online portion, an on-site portion and an off-site portion. The assessment work naturally leads to the development of the playbook.
The online assessment requires that each person throughout an organization complete an online survey about corporate culture. It includes three major sections: existing challenges, sense of urgency, and level of teamwork. This cultural survey is the foundation of understanding how to be successful with Real Agility. Managers and leaders are also asked to complete an additional questionnaire about the current environment at the organization. This includes high-level information about the structure of the organization, client and vendor relationships, and staff. Additional surveys may also be administered to understand other aspects of the organization. For example, in an organization that is struggling to use Scrum, we will often use the Scrum Team Assessment.
The onsite portion of the assessment combines in-person interviews and workshops with staff and managers. Interviews explore aspects of the corporate work environment in more depth and include questions about familiarity with Agile methods, and obstacles that people might see to adopting Agile. The workshops gather data around current challenges and strengths, success criteria for projects, situational analysis for teams, and existing metrics (or lack thereof). Typically we need a meeting room committed to our consultants for doing interviews.
The offsite portion of the assessment is used for us to evaluate and analyze the survey, interview and workshop results. We also use some time to review any relevant documentation such as process templates, org charts, governance requirements, etc. We may also use some of this time for follow-up phone calls or emails to clarify aspects of the assessment results. Finally, this offsite work is also where we do the bulk of the development of the recommendations in the playbook.
Several aspects of our assessment are based on the OpenAgile Catalyst Assessment Tools which are open-source and can be found online. We also have a number of proprietary tools.
The playbook maps out a path to a successful Real Agility transformation. It is a road map that helps leaders, managers and team members make good business decisions as they strive for Real Agility. The playbook aids the organization to effectively and appropriately launch Real Agility teams: management teams, project teams, and operational teams. The Real Agility Program playbook includes analysis of the assessment results, recommendations for work that the organization can do on its own and suggests outside assistance that enhances Real Agility results. Two critical questions that are answered in the Playbook include:
- What Agile method or methods should we be using and why?
- What organizational change approach should we take and why?
We deliver the recommendations in the form of the playbook and an executive summary slide deck in an iterative and incremental fashion so that stakeholders can give us early feedback and so that we can adapt our assessment agenda as we go along. The recommendations include ideas about organizational structure, staffing, governance changes, departmental relationships, tooling, and many other aspects of how an enterprise can best become and Agile enterprise.
Following the Recommendations in the Real Agility Program playbook results in huge time-to-market improvements, 200% (or better) productivity boost for delivery teams, and extremely satisfied customers and staff.
Wired magazine has a nice little summary of personal kanban. Check it out!
One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track. This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team. This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.
The very first thing, of course, is to establish who should be on the Leadership Transformation Team. There are six major categories from which the team must find representatives:
- The Executive Sponsor, for example the CIO
- Business Management, for example an SVP of Sales or Product Development
- Process Management, for example the head of the PMO or Compliance
- Technology Management, for example VP of Technology or Development
- Human Resources, for example a Director of Staff Development and Training
- and Apprentice Agile Coaches / Agile Champions
In total, the number of people on this team should be no more than 12, but smaller is better.
Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:
- Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
- Lead by Example: use of an Agile approach to run the Leadership Transformation Team’s work – we recommend OpenAgile for the process, but Kanban may also be used.
- Empower Staff: focus on removing obstacles by making structural changes in the organization, helping staff master standard Agile processes and tools, and eventually, creating innovative Agile approaches customized for the organization.
This leadership support is a critical success factor for an Agile Transformation. One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation. This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation. At a high level, these include:
- Hiring, performance evaluation and compensation
- Reporting relationships
- What to do with project managers, business analysts, testers and certain middle managers
- Key metrics and processes for measuring progress
- Technology and physical environment
- Vendor relationships and contracts
- Compliance, regulation and documentation
Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.
One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates. If something is part of their three core responsibilities, it must be handled directly by the members of this team. Therefore, the team members need to allocate a significant percentage of their time to the effort. Usually 20% is sufficient to get started. The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.
See also our article about the Recommendations component of the Real Agility Program.