Real Agility – Self-Organizing Team Creation Event for Large-Scale Agile Enterprises

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department.  What made it a success?

  1. Everyone participating already had Agile training and experience.  They knew what they were getting into and why they were doing it.
  2. Everyone was encouraged to participate through the way the meeting was facilitated.  No one felt like their opinion was ignored.
  3. The meeting was long, but also time boxed.  It wasn’t an open-ended discussion that could go forever.
  4. It was in-person!!!  Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
  5. It was honest: tough things were discussed including potential personality conflicts.  This open discussion required expert facilitation.
  6. Management was not involved in the decision-making during the meeting.
  7. The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
  8. A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
  9. Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group.  The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people.  Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day.  Longer is not recommended.  For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach.  If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work.  If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again.  A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready.  In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees).  As a result, the teams created in the team creation event were not really properly stable.  This caused a great deal of disruption and even significant morale problems for some teams.  It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event.  That includes any necessary means to encourage people who are thinking of leaving to reconsider.  It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:

PREPARATION

  1. Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
  2. The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
  3. The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
  4. In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group.  Is it for a specific Program?  If so, what is the objective of the program from a business perspective?  It should not just be a one-time communication.  This should come from the business Real Agility Coach.
  5. The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations.  These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.

TEAM CREATION EVENT AGENDA

  1. The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
  2. Management stakeholders make their presentations to ensure that participants have a clear vision.
  3. The business Real Agility Coach summarizes the vision presented by the management stakeholders.
  4. The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
    • Cross-functional
    • Multi-skilled (see the Skills Matrix tool for ideas here).
    • Correct size (usually 7 +/- 2).
    • People who want to work with each other.
    • People who want to work on that particular team’s goal (if such is set).
    • Everyone must be on a team.
    • Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
  5. Everyone starts self-organizing!  Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams.  These optimization opportunities should always be offered as suggestions rather than being directive.
  6. As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
  7. Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
  8. The people/process Real Agility Coach closes the meeting.  It is critical to record the final results of who is on which team.  It may be easiest to get the teams themselves to do this before leaving the meeting.

FOLLOW-UP

  1. The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
  2. The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone.  Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
  3. Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
  4. A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Enterprise Agility – Pragmatic or Transformative – Presentation to PMI South Western Ontario Chapter

Last night I had the honour of giving a talk at the PMI-SWOC. It seemed well received and I really enjoyed the opportunity. The slides from the talk are attached to this post.

20141202 PMI SWO Chapter – The Agile Enterprise [PDF]

There were quite a few people in attendance who were new to Agile and I spent a bit of time talking about the Agile Framework before really getting into the slides of my talk.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Foundations of Excellence

I was thinking about the concept of becoming excellent at something.  My son is a budding artist.  He and I had a conversation a few months ago about talent or aptitude.  I said to him that I felt that aptitude is only latent: you need to put effort into something in order to expose your talent.  He was concerned that he didn’t have any aptitude because he had to work so hard to become better at drawing.  I compared him to myself and my brother, Alexei: when we were growing up, we both put a lot of effort into drawing.  Quickly, I fell behind my brother in skill.  He clearly had aptitude.  But he also put in a lot of effort into exposing that talent.  I was reminded of all this because my son is struggling with math.  He has aptitude, but he hasn’t put much effort into it.  I was wondering why?

Then I realized that aside from aptitude and effort, two more things need to be in place to achieve excellence: willingness and confirmation.

Willingness is the internal drive, usually motivated by an unconscious set of factors, but sometimes also coming from a strong conscious decision.  Willingness can come from unusual combinations of circumstances.  I was extremely willing to learn mathematics in my youth.  This came from two experiences.  One, in grade 2, was when my teacher told me that I shouldn’t be learning multiplication (my dad had taught me while on a road trip).  I was upset that I shouldn’t be able to learn something.  Then, in grade 3, I had a puppet called Kazir (a gift from my babysitter who told stories about space adventures with Azir and Kazir the Baha’i astronauts).  I brought Kazir to school one day and while doing math problems, I pretended that Kazir was helping me.  Suddenly I found math easy.  These two events plus a few others contributed strongly to my desire, my willingness to learn math.

Confirmation is the set of environmental factors that helps keep us on a path of learning.  These environmental factors are sometimes mimicked in the corporate world with bonuses and gamification, but these are really distant shadows of what confirmation is really about. Confirmation is when the stars align, when everything seems to go right at just the right time, when the spirit inspires and moves you and the world to be, in some way, successful.  The trick about confirmation is that success is not usually about monetary success.  It’s usually about social, relational or even sacrificial success.  As an example, when I was in grade 7, I was chosen with a small group of people in my class to do accelerated math studies.  This was a great honour for me and was a confirmation of my interest in math.

In organizational change, and in particular in changing to an Agile enterprise, we need to be aware that excellence requires that these four factors be in place.  Aptitude is, to some degree, innate.  We can’t trick people to have aptitude.  If someone is just fundamentally bad at a certain thing, despite vigorous educational efforts, then that person likely doesn’t have the aptitude.  Effort is about both having time and resources, but also, then about willingness.  And willingness, in turn, can only be sustained with confirmation.  Too much discouragement will break a person’s willingness.  The Agile enterprise requires a great number of skills and abilities that are not normally part of a person’s work environment prior to attempting to adopt Agile.  Keeping these four things in mind can help people in an organization to reach excellence in Agility.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Book List for Enterprise Agile Transformations

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.

Culture

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.

The Corporate Culture Survival Guide – Edgar Schein

Beyond the Culture of Contest – Michael Karlburg

The Heart of Change – John Kotter

Management

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.

Good to Great – Jim Collins

The Leaders’ Guide to Radical Management – Steve Denning

The Mythical Man-Month – Frederick Brooks

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.

Scaling Lean and Agile Development – Bas Vodde, Craig Larman

Scaling Agility – Dean Leffingwell

Lean Software Development – Mary and Tom Poppendieck

Supporting

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.

Toyota Talent: Developing Your People the Toyota Way – Jeffrey Liker, David Meier

Agile Retrospectives – Esther Derby

Continuous Delivery – Jez Humble, David Farley

The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.

The OpenAgile Primer – Mishkin Berteig, et. al.

Priming Kanban – Jesper Boeg

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

SAFe Program Consultant Training – Review

I want to give some perspective on SAFe and the training that I have been attending these last few days.  The training itself is not actually over, but we are very near the end.  Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics.  In other words, we have covered the essence of SAFe.

Ad Hoc, Pragmatic and Transformative

When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.

The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means.  A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes.  When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations.  Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.

The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management.  There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom.  These pragmatic approaches typically have low risk and good results.  SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.

The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so.  There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours.  These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture.  LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.

SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.

Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile

One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto.  I want to say clearly and unequivocally that SAFe is most certainly true to Agile.  This fact was demonstrated multiple times and in multiple ways throughout the training:

  • Explicit statements that SAFe is based on the Agile Manifesto.  At one point, Dean Leffingwell emphatically repeated several times that “we live or die by the Agile Manifesto!”
  • Clear examples of SAFe implementations making choices based on the values and principles of the Agile Manifesto.  It was common to talk about situations where SAFe ScrumXP teams, Agile Release Trains and the people involved made decisions based on “individuals and interactions”.
  • Practices and guidelines that implement the values and principles of Agile are pervasive throughout SAFe.  The Inspect and Adapt meeting, Program Increments, daily business collaboration with SAFe ScrumXP teams, customer collaboration through various forms of backlogs, reviews and demos, focus on simplicity and technical excellence with Architectural Runway, Test-Driven Development and other Agile engineering practices.
  • The instructors (not just Mr. Leffingwell) often mentioned their own philosophy of being flexible with the SAFe “framework” by making appropriate context-specific changes to the details.
  • Even participants in the class who have already started using SAFe in their organizations shared stories that clearly indicated a strong emphasis on the values and principles of Agility.

At the same time, SAFe manages to create a relatively simple interface with a traditional management organization.  This is critical and what makes it really effective as a pragmatic approach to enterprise agility.  For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners).  The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level.  This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.

Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile.  But a different way of looking at the diagram is that it is comfort for management.  I really appreciate this.  Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort.  The project manager for an important project was very nervous that there was no Gantt chart in Agile.  At a personal level, she needed the comfort of having a Gantt chart to track the work of the team.  The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.”  Most Agilists are anti-Gantt.  This was a real eye-opener for me.  That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.

SAFe isn’t just a framework, it’s actually a scaffolding.  When you build an arch, you need a scaffold to keep everything in place until the keystone is in place.  In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.

Lean, Agile and Leadership

This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership.  SAFe asserts four principles of Agile Leadership:

  1. Take a systems view
  2. Embrace the Agile Manifesto
  3. Implement product development flow
  4. Unlock the intrinsic motivation of knowledge workers

I like this list.  I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.

There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”.  There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”.  There is also a lot of time spent on value stream thinking including some great discussion exercises.

Organizational Structure in SAFe

SAFe does not define all the structures throughout the whole organization.  By design, it is not end-to-end, top-to-bottom.  It does define a structure for three levels of activity: the team level, the program level and the portfolio level.

At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP.  As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations.  One example is in the idea of commitment.  Scrum espouses the value of Commitment.  In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope).  SAFe keeps this concept.  However, if you look in the most recent version of the Scrum Guide, this concept is no longer present.  One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring.  I wish that Scrum would get around to officially requiring these practices.  This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers.  And, in my not-so-humble opinion, SAFe is providing the right answers.  Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.

At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept.  The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150).  Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks).  Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level.  Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations.  This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features.  There are even a number of recommended metrics for evaluating the performance of the program (not the people).

At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small.  One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level.  At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership).  At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost.  This comes in many of the details, but may be a bit difficult for middle managers.  Fortunately, the Portfolio level  includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains.  SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.

The Training

I’ll admit that overall I didn’t particularly enjoy the training.  I love SAFe.  As a trainer myself, I’m too critical perhaps.  Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship.  However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.

There are a also some general comments about the training that I would like to make that are about personal preference.

First, I would prefer more small exercises that are experiential.  For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally.  The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).

Second, the slides.  The slides.  The slides.  The slides… and more slides!!!  Too much by far.  And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly.  This is anxiety-inducing and boredom-inducing for me.  Some people like lots of slides, but most people don’t.

Third, not enough breaks for a 9 to 6 training session.  Usually just one break in the morning and one in the afternoon as well as a short lunch.  Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level.  At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.

Final Words

I’m happy I invested in this for both myself and for Travis.  We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients.  At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.

I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

About SAFe – Lyssa Adkins

Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe.  (Thanks to Gerry Kirk for bringing this article to my attention!)

As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK.  I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights.  I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption.  I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Going to SAFe Program Consultant Training – London England

Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell.  For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting.  Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective.  I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program.  I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach.  This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge!  I’m looking forward to bridging that gap!

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Manifesto and Enterprise – Rant and Rave (Session Proposal)

I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“.  The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session.  If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization

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:

  1. 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.
  2. 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.)
  3. 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]

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Recommendations (Assessment and Playbook)

Recommendations IconWe 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.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Summer of Scrum Toronto 2014 Pre-Registration

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

- a 1-day “Advanced ScrumMaster” course
- a 1-day “Advanced Product Owner” course
- a 1-day “Managing for Success” course
- a 1-day “Enterprise Agile” course
- a 2-day “Agile Engineering Practices” course
- a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

Leadership IconOne 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:

  1. The Executive Sponsor, for example the CIO
  2. Business Management, for example an SVP of Sales or Product Development
  3. Process Management, for example the head of the PMO or Compliance
  4. Technology Management, for example VP of Technology or Development
  5. Human Resources, for example a Director of Staff Development and Training
  6. 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:

  1. Urgency and Vision: constant, strong, repetitive, prominent communication of the reasons for change and a high level view of how those changes will happen.
  2. 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.
  3. 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.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Reviews of SAFe (Scaled Agile Framework)

I just finished attending my SAFe Program Consultant (SPC) training and I wrote a review of the Scaled Agile Framework 3.0 and the SAFe Program Consultant training.  I won’t quote myself here :-)

Lyssa Adkins

Also, Lyssa Adkins has recently published her own review on InfoQ.  I enjoyed reading it because Lyssa is so gentle, fair, and insightful.  She puts a lot into connecting the Scaled Agile Framework with the Agile Manifesto and shows that there is a fantastic level of alignment between them.  Her article is called “Agile Coaches’ Coach Shares Her View on SAFe“.  Here’s a bit of a teaser from her article:

Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall…” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.

 

A surprising thing happened in that class…..

Peter Saddington

Although I don’t know him well, the few small interactions I’ve had with Peter have engendered in me a great deal of respect for him.  His fundamental philosophy of Agile and organizations is courageous and principled.  I found out yesterday that Peter wrote a review on the Scaled Agile Framework back in February 2014.  Please check out “The Scaled Agile Framework (SAFe) – A Review“.  It is interesting and insightful.  Great quote:

What SAFe is Far Better At Than Most

- Marketing

Ron Jeffries

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

 

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Mike Cohn

Mr. Cohn has written a really fun April fool’s parody of SAFe that, given the comments, surely counts as a review as well.  It’s called “Introducing the LAFABLE Process for Scaling Agile“.  Although it starts on a very humorous note, the comments are quite extensive and contain lots of great discussion.  Here’s an important comment from Mike Cohn about the whole concept of scaling that gives you a taste of the discussion:

I don’t think “agile at scale” is a bad word. I’ve consistently maintained that projects should be as agile as they can be but no more. A project that requires let’s say 500 people will never be as agile as one that requires 3 people. But I can’t imagine the 500 people and 3 people being competitors. And, if they are, the bigger mistake made by the 500 person project is involving the other 497 people, not the process they choose.

Neil Killick

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

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 information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail