Tag Archives: transformation

Formula for Building a Successful Scrum Experience

Learn more about transforming people, process and culture with the Real Agility Program

Under the right conditions Scrum can be a tremendous success story, but it often requires hard work to get there.  For new Scrum teams it means learning to fundamentally work very differently than they are used to, such as relying on a lot more collaboration, making and delivering on shared commitments and building a high degree of trust.  For existing Scrum teams it means constantly renewing the team commitment to each other, the cause, and to the Scrum framework.  This includes the rather painful practice of revisiting the fundamentals and ensuring any deviations from accepted processes or practices were for the right reasons and had the right results.

To have a chance at achieving high performance a new-to-Scrum team will not only need to just change their processes, but fundamentally change the culture and behaviour of the team and all of the supporting roles (that includes their leadership).  Meanwhile, a mature or well-established team should never assume they are high performance; they should always be checking (and rechecking) that they are still living the Agile values.

Needless to say this can become an extremely complex challenge!  To be absolutely clear, I’m not proposing there is a single formula or recipe that works, but I do believe certain criteria can dramatically improve your Scrum team’s chances of success.  To that end here are 10 tips (plus a bonus) that may help you focus your efforts towards building a successful Scrum team and experience.

 

1. Right Number of Team Members

Currently the Scrum Guide recommends that Scrum teams will work best with three to nine people (not including the Scrum Master and Product Owner).  Too few people on the team and you risk not having enough technical expertise and coverage of critical skills.  Too many people on the team and you may become challenged to truly collaborate effectively.  Remember, this is just a guideline and you may be successful with different numbers, you just need to be aware of the impacts and make sure the gaps are covered.

2. Appropriate Balance of Skills

Scrum teams really should be balanced and cross-functional.  Having all of the necessary skills on the team for delivering a complete solution (not roles, but skills) will encourage and support end-to-end thinking all the way from design to implementation.  This approach will result in a better solution and a superior customer experience, but it relies on whole team collaboration.  Note this does not mean individual team members need to be fully cross-functional, but what is important is that all the critical skills are represented on the team and each team member contributes their domain expertise towards the collective strength.

3. Propensity for Engineering Technical Ability

For increased chances of success, a Scrum team should leverage technology and engineering practices whenever possible.  Techniques, skills and tools that facilitate Agile approaches such as Continuous Integration, Automated Testing and Test Driven Development all make technical excellence, continuous improvement and truly being “Done” every Sprint a possible reality for a Scrum team.

4. High Team Member Allocation

Scrum team members should be allocated to as few different initiatives as realistically possible.  The more projects you are allocated to, the more task switching you may have to perform, the longer it will take to complete any one item, the thinner you will be spread and the less effective you will be.  In other words, people (and teams) should limit their work in progress as much as possible and focus on completing those things that truly matter most.  This is true for any framework, but it is particularly emphasized with Agile ones.  Note there is a slight but fundamental difference between being allocated to a team and being dedicated to a team – that is a topic for a future article.

5. Empowered and Knowledgeable Product Owner

Your Product Owner needs to be informed, available, business-savvy, knowledgeable, collaborative, and empowered to make decisions about what to build and what order to do it in.  They also need to be a strong negotiator and very capable at conducting business driven trade-offs.  In the end, a Product Owner needs to effectively communicate, convey and deliver on a clear vision to the Team and Stakeholders to ensure a useful solution is created.  Without empowerment, knowledge, and vision in a Product Owner the team will struggle.

6. Equitable Scrum Master

Having a good process is only part of the equation.  A good Scrum Master will champion and enforce that process, protect the team, encourage collaboration, highlight (escalate when necessary) and encourage the removal of obstacles, facilitate discussions, provide fair and constructive feedback, cultivate a culture of continuous improvement and learning, and work to help the team live the Agile values.

Remember that the Scrum Master has authority over the process but not over the team.  As the process champion the Scrum Master may sometimes even find themselves in a conflict between maintaining the Scrum rules and guiding the team as they discover the need to adapt practices to better align with their own needs and ways of working.  In that regard a Scrum Master should understand and embrace the servant leader role.  In the end, a Scrum Master needs to be the person that helps the team make decisions, but not the person that makes decisions for them.

7. Strong Executive Support

Leadership is the key to driving change and progress.  Executives and managers of Scrum teams need to nurture the environment, let go of the “how”, allow the team to learn from mistakes, and encourage and coach the growth of the collective team knowledge and overall experience.

Understanding the dramatic impact leadership has on a transitioning team is also very critical, as a single word or direction from the executive level can single-handedly affect (either positively or negatively) the team’s future behaviours and resulting successes or failures.  And without a true environment of trust built by the leadership, team members will often shy away from taking a risk to try something new or unknown.

8. Solid Partnership Commitment

There must be a consistent commitment and engagement from all parties in the organization towards adopting the Scrum framework, Agile methods, and thinking.  The initiative must be an open, collaborative experience and there must be complete understanding  and alignment by all parties in assuming the risks and rewards as well as sharing in the effort.  This includes not only business partners and their IT counterparts, but their leadership as well as all of the people and teams supporting an Agile initiative.

9. Reduced Team Dispersion

Co-located teams are more effective communicators and can sometimes experience increased productivity by up to 60% if situated together in the same room.  More simply stated, the greater the dispersion factor, the greater the challenge of collaboration.  Note that time zones are often considered the largest dispersion factor and can have a greater impact than geography.

Although it is strongly recommended that teams be co-located, it is not mandatory to success.  In fact, certain Agile practices have factors, tools and techniques inherent to them to help bridge some of the shortcomings of increased dispersion, such as a higher reliance on frequent collaboration and communication.  But to be clear, they do not replace the value of face-to-face conversation, they are merely a crutch to not having it.

10. Consistent Education and Coaching

To ensure consistency and a shared understanding, whole teams (including the business, IT, and their leadership of executives and managers) should receive a common skills development and education experience in proper Agile Thinking, the Scrum Framework, aligned practices and mindset training.  Coaching should then reinforce this new knowledge and encourage appropriate behaviours to turn these new practices into habits.  Indeed, learning should be a continuous cycle and endless journey towards excellence, and Scrum leverages this through frequent retrospection and continuous improvement.

11. The Right Attitude!

Mutual respect and caring are the cornerstone to the team’s success and it needs to be integral to their culture and beliefs.  Not just saying but living the belief there are no heroes or scapegoats.  Everyone, including the business, executives, team members and leadership must collaborate and share in celebrating the successes as well as accepting responsibility for setbacks and failures.

Everyone must have the right attitude and commit to not only DOING as needed by attending the ceremonies or following the process and practices but truly wanting to BE part of the solution by willingly changing the way they think, work and collaborate.

 

At the end of the day your goal should not be to become Agile or Scrum savvy.  Instead your real goals and outcomes should align with achieving the key benefits of Agility, and with what Scrum offers.  These should include (but are not limited to) increased customer satisfaction, faster delivery of value, improved feedback loops, adopting a continuous improvement mindset, improved employee morale and increased employee retention.  Scrum is just one of the many tools or approaches you may choose to get there, but it is certainly an important one to consider if these outcomes align with your goals.

For Scrum to be truly successful at your organization, you must dramatically transform your very culture and business approach.  To be clear, this is not easy to do but the rewards are well worth the effort.  By embracing such a transformation, the adopted change in behaviour, beliefs and practices should result in a more successful Scrum experience and a higher degree of satisfaction for both your customers and employees.

Can you think of other success factors that might help your Scrum team succeed?  There are lots, so feel free to reach out and share them below.

 

Thanks to Photographer: Chris Potter for this awesome photo.

Sourced from stockmonkeys.com | Flickr Portfolio


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Thinking About the Agile Manifesto

Learn more about transforming people, process and culture with the Real Agility Program

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Succeeding with your Agile Coach

Learn more about transforming people, process and culture with the Real Agility Program

 

I recently said goodbye to one of my organization’s Agile Coaches and I felt that I needed to take a pause and reflect to consider my next move. The engagement had gone well, in fact one of the best we’ve had, but not without its share of successes and failures. But the successes had clearly outpaced any failures, and so there was a lot of good I wanted to build on.

The departing coach was part of a 3rd generation of Agile Coaches that I had worked with in the 3 years since we had begun our company’s transformation to Agile. And while he was a great coach, so were his predecessors and yet they had had fewer successes.

On reflection, what had really happened is that we had changed as a company; we had learned how to better execute our engagements with an Agile Coach.

Deciding to hire an Agile Coach.

Deciding to hire an Agile Coach can be a big step. A couple of things need to have happened, you’ve recognized that you need some help or at least another perspective. And given that Agile Coaches are typically not very cheap, you have decided to invest in your Agile transformation, however big or small. You’re clearly taking it seriously.

However, through my experiences I noticed that things can get a little tricky once that decision has been made. Many organizations can fall into a trap of externalizing transformation responsibilities to the Agile Coach.

In essence thinking along the lines of “as long as I hire a good coach, they should be able to make our teams Agile” can take you into an engagement model that is not very Agile in the first place.

Much like how Scrum and other Agile Practices connect customers with teams and establishes shared risk, an organization’s relationship with their Agile Coaches need to be a working partnership.

Figure1

Positive Patterns for Coaching Engagements

So it’s important for you to setup the right engagement approach to get value out of your Agile Coach and this goes beyond the hard costs of their services, but also the high cost of failure with not having the right coaching in the right areas.

Here are 5 positive patterns for coaching engagements that I’ve observed:

1. Identify the Customer

Usually it is management who will hire a coach, and they may do so to help one or more teams with their Agile adoption needs. So in this scenario who is the customer? Is it the person that hired the coach or the teams (the coachees) who will be receiving the services? In some cases, the coachees aren’t clear why the coach is there, they haven’t asked for their services and in some cases may even feel threatened by their presence.

For this reason, if management is hiring coaches you need to recognize that there is a 3-pronged relationship that needs to be clearly established and maintained.

Figure2

With the customer in this case being someone in management, i.e. the person who hired the coach in the first place. The customer’s responsibility will be to not only identify the coachee but then work with the coach to establish and support that relationship.

2. Set the Mandate

Agile Coaches typically tend to be more effective when they have one or two specific mandates tied to an organization’s goals. Not only is the mandate important to establish why the coach is there, too many goals can significantly dilute the coach’s effectiveness. Put another way, Agile Coaches are not immune to exceeding their own Work in Progress limits.

The mandate establishes why the coach is there, and should be tied to some sort of organizational need. A good way of developing this is to articulate what is currently happening and the desired future state you want the coach to help with.

For example:

The teams on our new program are great at consistently delivering their features at the end of each sprint. However, we still experience significant delays merging and testing between teams in order for the program to ship a new release. We’d like to reduce that time significantly, hopefully by at least half.

Once the engagement is well underway you may find that the coach, through serendipity alone, is exposed to and gets involved with a wide variety of other areas. This is fine, but it’s best to just consider this to be a side show and not the main event. If other activities start to take on a life of their own, it’s probably a good time to go back to inspect and potentially adjust the mandate.

If you’re not sure how to establish or identify your Agile goals, this could be the first goal of any Agile coach you hire. In this scenario, the customer is also the coachee and the mandate is to get help establishing a mandate.

3. Hire the Coach that fits the need

Agile coaches are not a homogeneous group, with many degrees of specialty, perspective and experiences. Resist the desire to find a jack-of-all-trades, you’re as likely to find them as a unicorn.

Your now established mandate will be your biggest guide to what kind of coach you should be looking for. Is the need tied to technical practices, process engineering, team collaboration, executive buy-in, transforming your culture, etc?

The other part is connected with the identified coachee. Are the coachees team members, middle management or someone with a “C” in at the start of their title? Will mentoring be required or are you just here to teach something specific?

Using something like ACI’s Agile Coaching Competency Framework, would be a good model to match the competencies required of the perspective coach.

In my example earlier, in order for your team to get help with their merging & testing needs, you may have to look for a coach with the right skills within the Technical Mastery competence. And if you have technical leaders who are championing the change, potentially the ability to Mentor.

Figure3

4. Establish Feedback Loops

With the coach, customer and mandate clearly identified, you now need to be ready to devote your time to regularly connect and work with the coach. Formalizing some sort of cadence is necessary, if you leave it to ad hoc meetings you will typically not meet regularly enough and usually after some sort of failure has occurred.

The objective of these feedback loops is to tie together the communication lines between the 3 prongs established: the customer, the coach and the coachees. They should be framed in terms of reviewing progress against the goals established with the mandate. If the coachees ran any experiments or made any changes that were intended to get closer to the goals, this would be the time to reflect on them. If the coachees need something from the customer, this would be a good forum to review that need.

Figure4

Along with maintaining a cadence of communication, feedback loops if done regularly and consistently, could be used to replace deadlines, which in many cases are set simply a pressure mechanism to maintain urgency. So statements like “Merge & test time is to be reduced by half by Q2” now become “We need to reduce merge and test time by half and we will review our progress and adjust every 2 weeks.”

5. It doesn’t need to be Full Time

Resist the temptation to set the coach’s hours as a full-time embedded part of the organization or team. While you may want to have the coach spend a significant amount of time with you and your coachees when the engagement is starting, after this period you will likely get a lot more value from regular check-ins.

This could look like establishing some sort of rhythm with a coachee: reviewing challenges, then agreeing on changes and then coming back to review the results after sufficient time has passed.

This approach is more likely to keep the coach as a coach, and prevents the coach from becoming entangled in the delivery chain of the organization. The coach is there to help the coachees solve the problems, and not to become an active participant in their delivery.

Time to get to work

Bringing in an Agile Coach is an excellent and likely necessary part of unlocking your Agile transformation. However, a successful engagement with a coach will have you more connected and active with your transformation, not less. So consider these 5 positive coaching engagement patterns as I consider them moving into my 4th generation of Agile coaches. I expect it will be a lot of work, along with a steady stream of great results.

Martin aziz

Martin Aziz
Blog
@martinaziz
LoyaltyOne

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Agile Coaching and Flight Instruction – An Emotional Connection

Learn more about transforming people, process and culture with the Real Agility Program

My friend Mike Caspar has another great blog post: Similarities between Agile Coaching and Flight Instruction.  Check it out!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation Metrics

Learn more about transforming people, process and culture with the Real Agility Program

TL;DR

When asked to provide metrics to assess “how well” an Agile transformation is going, re-frame the discussion around measuring changes in the impact the IT organization is having (or not) on it’s Business environment, and define a small set of “fitness for purpose” metrics.

The Inevitable Question about Agile Transformation Metrics

Sooner or later, as an IT organization embarks on a transformation towards Agile mindset and practices, someone will be asked to provide “hard evidence” that the effort is paying off, and the conclusion will be that metrics is the vehicle to satisfy that request. What are your Agile transformation metrics?

It’s been my experience that this request usually leads to a discussion about measuring the specific Agile initiatives the IT organization has launched. In organizations where the emphasis has been around engineering disciplines, such metrics might be things like unit test code coverage, or integration build times. If the focus  was around teams and process, then counting number of teams “converted” to Scrum, or people sent to Scrum Master training may appear as the choice.

While those measurement might be useful indicators in some context, they have two problems. First, they are akin to measuring the performance of the car engine without looking outside the window; the engine might be performing well, but if the car doesn’t have the wheels attached, we’re going nowhere. More importantly, though, these figures are usually meaningless for Business stakeholders, who are the ones usually asking for them in the first place.  Agile transformation metrics need to be meaningful to the Business.

Re-framing the Agile Transformation Metrics Question

Agile transformation efforts can be very costly exercises, therefore it is legitimate to ask about the results of such endeavour. The important thing to realize, though, is that this question is really equivalent to another question: “is the IT organization improving its impact on its Business environment.” Another way to put it is, borrowing from the terminology used by the Kanban community: “is the IT organization becoming more and more fit for purpose?” Answering this question, of course, requires a clear understanding of what is that the Business expects from its interactions with IT.

The IT organization can be seen as providing various services to customers. Arguably, if IT has decided to “transform” in some way (perhaps by moving towards an Agile mindset), it’s doing so to improve its impact on those customers, so this is what needs to be measured to know “how the transformation” is going.

Some of those customers are different areas of the organization (like Finance, or HR.) But it doesn’t stop there, because the Business’ engagement with IT doesn’t have value for its own sake. Ultimately, the Business is using IT as a way to optimize its operations so that it can provide external customers with more effective products and services. Moreover, IT is these days the direct channel through which those products and services are delivered to external customers (for example, through web sites and mobile applications.) Therefore, the concept of “fitness for purpose” of the IT organization can be extended to consider the fitness for purpose of the Business respect the external customers it intends to serve.

Defining the “Agile” Transformation Metrics

Measuring “agile transformation success” really means measuring the success of the exchanges between IT and the Business, and between the Business and its external customers.  Measuring the internal processes and practices that IT puts in place as part of that “transformation” is beside the point. This implies starting with a careful definition of the boundaries that delineate the exchanges to be measured. There might be more to external customer fitness for purpose than IT operations, for example, and that needs to be considered when defining Agile transformation metrics, especially if we’re later going to be drawing causation conclusions.

Defining Agile transformation metrics will be, of course,  a highly contextual exercise because every business organization is different.  But we can, however, draw again from the Kanban community for some general guidelines on what to look for. Their thought leaders talk about classifying metrics into 3 categories: fitness for purpose metrics, health indicators and improvement drivers.  Using this framework, when talking about “agile transformation metrics” we are referring mainly to the first category, and perhaps a bit to the second. Based on those, improvement initiatives can be put in place, and perhaps driven with metrics belonging to the third category.

A fitness for purpose metric (also known as KPI) is an indicator of something a customer will care about. This is a key distinction: if the metric is not easily recognizable and meaningful for the customer, then it’s not a KPI. Another key characteristic is that a minimum threshold for its value can be defined: if the metric goes below the threshold, the Business is putting the relation with its customers at risk (perhaps they will walk away, initiate legal actions, etc.). In other words, the Business is no longer “fit for purpose”. We can then measure the effectiveness of the “agile transformation” by analyzing how KPI values over time compare to their respective thresholds. A typical KPI is delivery time, measured from the moment a customer request is accepted and committed to, until the moment it’s delivered to production.  This is usually a good Agile transformation metric.

Health indicators are metrics that are inwards facing. Customers don’t really care about them (or even understand), but they indicate how a given aspect of the system is operating. The key characteristic is that they are not directly actionable; they only provide information that needs to be analyzed and put in context. As the value of a health indicator changes, we can draw some conclusions about how the system works, or explain why something is happening (or not), but it doesn’t necessarily leads to concrete action. Defect count is an example of this. Customers will certainly care about quality of the product, and we can make inferences about that quality by looking at how many defects we have, but the absolute number of defects will not necessarily make the product more or less fit for purpose. It may happen that customers consider the current quality to be “good enough”, irrespective of the number of defects.

Finally, improvement driver metrics are metrics put in place to influence behaviour towards a particular change. Their key characteristic is that they are temporary: we set a target on them and once the target is achieved, the metric is no longer necessary. The reason for this is related to the unintended behaviours that a metric might encourage in people, which may lead to locally optimizing the metric at the expense of other aspects, leading to global sub-optimization of the system. An example is unit testing code coverage: if we have determined that a given service is not fit for purpose and the cause is related to poor unit test coverage, then establishing a target for minimum coverage may influence developers to work on adding tests to reverse the situation.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Nexus Reifies

Learn more about transforming people, process and culture with the Real Agility Program

Nexus Scrum

I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexusa connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Spark the Change Toronto – Pre-Registration Started

Learn more about transforming people, process and culture with the Real Agility Program

This looks like a great conference – to be held on Thursday, April 23rd, 2015.  From the description:

An event for the whole organization, Spark brings together leaders from across the business to explore how they can work together to create lasting and total change. Talks and workshops offer inspiring examples and practical advice on taking action and overcoming obstacles. – See more at: http://2015.sparkthechange.ca/what-is-spark-2/#sthash.WI3bDFBA.dpuf

Sign up for pre-registration for Spark the Change Toronto


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Book List for Enterprise Agile Transformations

Learn more about transforming people, process and culture with the Real Agility Program

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


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Real Agility Program – Leadership Transformation Team

Learn more about transforming people, process and culture with the Real Agility Program

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:

  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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Learn more about transforming people, process and culture with the Real Agility Program

Most organizations don’t get the potential benefits of Scrum.  In fact, I would guess that out of all the people who have come through my Certified ScrumMaster or Certified Scrum Product Owner classes, fewer than 5% have gone back to their organizations and seen the 4 to 10 times growth in productivity that Scrum can enable.

Why?

Pragmatism – Arrogance and Defeatism

Pragmatism as applied to Scrum is the approach of taking only the “good things that are possible for us” from Scrum and using those in a team or an organization.  This might mean doing the Daily Scrum meeting, but giving up on many of the obstacles raised there because they are too hard to overcome.  Another common example of this is creating a team of technical people who contribute time to the Scrum Team and possibly to other priorities instead of the idea of creating truly cross-functional teams with all members fully committed to the Scrum Team.

This pragmatism often results in some benefits: better communication among team members, shorter feedback loops with users and customers with the team, or a stronger focus on business value for the scope being worked on by the team.  It might amount, in practical terms, to a 15-25% productivity improvement.

But, really, it sucks, and it’s not Scrum.

For teams and organizations that are new to it (three years or less), this is like an individual going to a dojo to learn Karate and, after the first session, telling the Sensei, “hey, this was really interesting but I can’t stretch that way so I’m going to do the kick differently – don’t worry, it’s better than what I did before – let’s move on to other things that I can do!”.  In other words, it’s arrogant and defeatist.  Regrettably, a lot of arrogance and defeatism goes by the much more palatable label of pragmatism.

You can’t make up what you want to do and call it “Scrum”.  Scrum has a definition (which has changed somewhat over time) and if you do something different from the definition, please call it something different.

But please, don’t mistake my comments for a call to…

Fundamentalism – Inoculation Against Scrum

It’s less common, but some people go here.  They learn Scrum the one true way and decide that come hell or high water, they will make their team do it that way!  Scrum this way is rigid and cultish.  Nevertheless, done this way, Scrum can still have some (temporary) benefits, similar to the pragmatic approach.  The challenge here is that it’s not usually sustainable and the people who participate in this type of Scrum are often “immunized” against it.  They’ve had a bad emotional experience with Scrum due to the inflexible, intolerant approach to implementing it.  Justifiably, those people don’t want to repeat the negative experience and so they actively avoid Scrum or even bash Scrum publicly.

It really is a process very much like how our antibodies work in human health: we are exposed to a microbial disease which itself may temporarily succeed in propagating in our body, even long enough to get us to infect someone else.  But after our immune system fights it off, we are ready for the next attack, will recognize it and repulse it far more quickly so that it can’t spread.  Trying to spread Scrum by doing it as an invasive take-over of an organization is very likely to cause the same sort of reaction among the people in the organization.  And anyone who comes along a little while later, even with a much more appropriate way of doing Scrum will likely be quickly rejected by the long cultural memory of the Scrum antibodies!

So where does that leave us?  There really is only one option for doing Scrum, allowing it to flourish, and getting amazing long-term results:

Transformation – The True Potential of Scrum

Remember that Scrum is based on the values and principles of the Agile Manifesto, and that Scrum itself has five values:

  1. Commitment
  2. Courage
  3. Focus
  4. Openness
  5. Respect

Taken all together, these values and principles constitute the spirit of Scrum.  They are the belief system.  They are the energy behind the framework.  This means that as a team uses Scrum, it must recall these values and principles and try to put them into practice through Scrum.  Not just the team, but the team’s stakeholders also need to be aware of these values and principles and also try to put them into practice.

For example, if you are a functional manager for someone who is on a Scrum Team, it is tempting to ask that person to do work that is not actually part of the Scrum Team’s plan. This is a distraction and causes both the individual person and the other Team members to lose focus.  Losing focus delays or prevents the creation of a high-performance team.  Therefore, as a functional manager, it is much better for you to “cover” for your subordinate, not distract them, and in every way allow that person to focus on their work for the Scrum Team.

Transformation doesn’t come just from adopting a set of values and principles, nor does it come from using a framework of processes and artifacts.  Transformation requires love and passion.  Transformation occurs when all the members of the Scrum Team, and their stakeholders start to develop intense personal bonds and become passionate about the potential of using the Scrum tool.

I really like the “hammer analogy“.  When you first use a hammer, you will likely find it annoying and painful to use.  You hit your thumb, your muscles get tired, etc.  But after getting better at using it, you start to see its potential: the hammer is an elegant, effective tool.  In a small way, you love the hammer, in part because of the results you can get with it.  Perhaps you have experienced this if you have ever tried to finish an unfinished basement: after you successfully put up your first stud wall, you think, “wow, I love doing this.”  That sense of accomplishment gives you the passion to continue to use the hammer.  So it is when using Scrum…

you allow Scrum to transform you and your organization not the other way around.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Advice Book

Learn more about transforming people, process and culture with the Real Agility Program

Hi Everyone!  I’m writing a compilation book of the best articles of Agile Advice (as well as some that may not have been so popular, but which I think are important).  I was wondering what you all think are the best articles from our archives so that I can be sure to include them!  The best way to vote, since there are soooo many articles about Agile, Scrum, OpenAgile, Management, Org Change etc. etc. is to simply write a comment on the articles you think are the best and worth including in a book!  You can comment on any of the articles: feel free to brows through the archives, go by subject, do searches, etc.  As well, if you have any suggestions for specific blog posts that you always wish I had written, please comment in the section below.  I will be including three brand new articles in the book that won’t be published here as stand-alone articles.  If there are enough interesting suggestions for articles in the comments here, I will also choose up to three ideas to write about for special inclusion in the book and if you made the suggestion, I will including a credit to you for the question (if you want me to, otherwise you are free to remain anonymous).  I’m hoping to get the first draft of the book out by the end of January since I’ve already put a lot of work into it, and that draft will be available for free here online for a limited time.  The final draft will be self-published and I will provide links here to those who want to purchase it.

Thanks for your loyal readership and thanks in advance for your votes and suggestions!

– Mishkin.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What’s in your Agile Transformation Backlog?

Learn more about transforming people, process and culture with the Real Agility Program

Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?.  From his question:

While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation and the Chasm

Learn more about transforming people, process and culture with the Real Agility Program

In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later.  He describes five types of people in relation to how they adopt new products:

  • Innovators – always actively seeking out and trying cutting edge new products.
  • Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
  • Then there is the Chasm – many products fail here.
  • Early Majority – willing to try new things but need strong testimonials or real-world proof.
  • Late Majority – require time-tested proof before they will adopt a product.
  • Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.

This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.

Implications of the “Chasm” Model

An organization attempting to do an Agile Transformation [Kotter’s 8-Step Change Model] should understand how to use this model to ensure long-term success.  This diagram illustrates the concepts (click on it to see it full size):

First, the organization should start the transformation by finding the innovators and early adopters.  These people can then be recruited to run the initial pilot projects.  They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility.  If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment.  Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.

In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups.  These people will tend to drag on the results of the pilot projects.  This is a common mistake in running a pilot program and leads to discouraging results.  One way to help filter between these two groups is simply to ask for volunteers for the pilot projects.  Innovators and early adopters will be much more likely to volunteer for a new initiative.

After the pilot projects have shown some good results, the next step is to go the general roll-out.  In this step, you are now working with the early and late majority.  These people need much more substantial support for a change of this nature.  They will require intensive training, and hand-holding in the form of coaching and mentoring.  This hand-holding can come partially from your innovators and early adopters.  Some of the participants in the pilot projects will have the desire to share their success.  From these, you need to carefully select and prepare a few who will act as internal coaches.  If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.

The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated.  This evidence partially comes from your pilot projects.  However, this may not be sufficient.  There are two other important sources of evidence for this group: the leadership team and external experts.

The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team.  The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar.  As well, this “Agile Transformation Team” must make itself very visible during the general roll-out.  This can be done with communication and by taking up visible residence in a central conference room or bullpen.  As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.

The second source of evidence comes from external sources.  Published case studies are one valuable source.  However, there is a huge value in a visible management investment in external support from recognized experts.  This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like.  When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.

The final stage of a roll-out is to deal with the laggards.  For the most part this is a do-or-die proposition for these people.  Either get with the program and engage like a committed employee or leave the organization.  If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.

For some organizations, this transformation process can take many years.  An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years.  Often it will be longer.  Good luck on your agile transformation effort!


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Outside of Software

Learn more about transforming people, process and culture with the Real Agility Program

The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:

1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan

I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.

On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.

Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Planning Onion is Wrong

Learn more about transforming people, process and culture with the Real Agility Program

The concept is simple: there are six levels of planning in an organization, often represented as layers of a metaphorical onion. In the agile planning onion, strategy is the outermost layer. This is meant to indicate that it is the driver of all the planning in the inner layers, which have shorter time horizons, down to the daily planning that occurs in the Daily Scrum or the Daily Standup of the agile teams.

Culture is Missing

The agile planning onion is a reasonable metaphor, but it has a serious limit: culture is missing. Many of you will have heard the quote “Culture eats strategy for lunch [or breakfast]” (attributed to quite a number of different people – I’m not going to sort out who was the original). How do we represent culture on the onion? Is it a seventh layer on the outside? Maybe, but for most organizations, culture is not planned.

Single Loop Learning

The main problem with the planning onion is that it gives no indication that the planning cycles deal with anything but the product / business side of the work. This implication of single-minded focus gives us permission to limit ourselves to improving our products. This is learning, but it is limited. It is sometimes referred to as “single loop learning”. We make improvements, but never question our underlying beliefs, habits or goals. All improvement (and planning) is within the narrow guard rails of a product mentality.

Double Loop Learning

Culture both surrounds the planning onion, and cuts right through it (nice way to extend the metaphor!) The problem with a visual metaphor that does not include culture is it means that culture remains unconscious. As individuals we might, from time-to-time, find that the organization’s culture clashes with our own expectations, habits or beliefs. But other than this occasional dissonance, we are like onions in dirt – completely unaware of the dirt, yet completely utterly dependent upon it for growth (couldn’t use “fish in water” because that would have introduced a different metaphor – I’m trying for consistency).

In the best agile transformations, individuals, teams and organizations become aware of their culture and consciously work to change it. This is usually due to a strong clash between their current culture, and the behaviors, norms and attitudes of a embryonic agile culture. In Scrum, we find impediments and remove them. In OpenAgile we look for learning about product, process and people. This is, again, roughly speaking, double loop learning… it is learning about learning and applying this to our belief systems, our habits and our attitudes.

Transformation vs. Adoption

Those who share the agile planning onion model, probably don’t realize its limits. I would like to strongly encourage those who use this model to consider re-framing it in terms of culture and organizational learning, rather than planning. I’m terrible at diagrams – I hope someone out there will consider creating a new compelling Agile Learning Onion diagram to show that agile is about Transformation, not merely adoption of planning practices.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail