REPLAY OF EXPERT VIRTUAL PANEL

CPrime hosted virtual panel with top SAFe/DevOps leaders in the industry: Zubin Irani, CEO of cPrime; Ken France, CEO of Blue Agility; Brandon Cipes, VP of DevOps at cPrime, & Dr. Steve Mayner, SPCT & Senior Consultant at Scaled Agile. Wednesday, Aug 16 at 2 pm ET.

Scaled Agile recently announced a more formal integration and stronger focus on DevOps and Continuous Delivery in the most recent 4.5 release of the SAFe framework – more specifically a “CALMR” approach to DevOps. C – Culture. A – Automation. L – Lean Flow. M – Measurement. R-Recovery. Is it just another acronym I need to learn? Is it any different from the way I develop and deliver? What does it really mean in real-world implementations?

In this Web Event, you will learn: The underlying value of the acronym! How our partners define and implement each one of the values; the successes and challenges they’ve encountered in real-life; and opportunities stemming from DevOps & Continuous delivery when done right.


Innovation and efficiency have reached new heights and their combination into cyber physical systems has led to more complex and interdependent systems. How can we sustain such a pace for the future and continually evolve systems in the shortest possible lead time, especially in the context of regulated environments?

Company Logos

The last 10 years have seen the disappearance of well-known products and the arrival of new competitors in the marketplace. Who would have thought in 2007 that Nokia would disappear as one of the great brands in mobile phone and that Apple would take over the Smart Phone Market almost overnight? With the rise of new competitors such as Uber, Tesla, Airbnb, Netflix, Google, Facebook and others, we witness the rise of competitive pressure in all industries and new levels of innovation and efficiency are required. As we combine such systems into cyberphysical systems with the Internet of Things (IoT), Industrie 4.0, Lean Start Up, and Agile, we move into an increasingly complex and interdependent realm.

Creating agile teams has helped to get where we are today, but we also face limitations, as small teams cannot build such complex systems in a timely manner. We also have to face regulatory and organizational environments, which are becoming increasingly demanding. A study by Scott Ambler from Disciplined Agile Delivery (DAD) shows that most agile delivery teams (>65%) are facing compliance requirements, either regulatory and/or organizational. Given this situation, it is clear that we need a strategy and a governance to steer such endeavors.

In the recently published study ‘State of Agile’ by Version One in April 2017, we find that the Scaled Agile Framework (SAFe) has overtaken all other scaling agile methods and remains at the top for existing frameworks in practice.

State of Agile

With regard to agile maturity, the report states that only 18% think that they have reached ahigh competency with agile practices across the organization. The remaining 80% of the companies are aware that they have to improve.

This is a strong indicator that scaling agile is really accelerating. It’s ‘Where the rubber hits the road’; and it’s getting serious because we are building complex and high assurance systems.

Example of a #1 Framework for Scaled Agility – SAFe

The assumptive, one pass, stage-gated, waterfall methods of the past have not scaled to the new challenge. We need more responsive development method to address the demands of the modern technological and cultural landscape. Agile is a major step in that direction. However, Agile was developed for small teams, and by itself, does not scale to the needs of the larger enterprises and the systems they create. That’s where SAFe comes in. It applies the power of Agile, but takes it to the next level by leveraging the more extensive knowledge pools of systems thinking and Lean product development. SAFe provides comprehensive guidance for achieving the benefits of Lean-Agile development at enterprise scale.

When you start with the Framework, it is important to understand the reasons why these approaches work, not just what they are. That’s why SAFe is based on Lean-Agile principles. The better we understanding how things work, the more easily we can apply them to our unique context. SAFe principles apply on each level of the framework to realize complex cyberphysical systems. The SAFe big picture shows the four levels of SAFe, starting with the team level on the bottom, which is a representation of an agile team, the rest is scaled agility including cadence, alignment, feedback and transparency.

The framework adopts principles like:

  • Take an economic view
  • Apply systems thinking
  • Assume variability; preserve options
  • Build incrementally with fast, integrated learning cycles
  • Base milestones on objective evaluation of working systems
  • Visualize and limit WIP, reduce batch sizes, and manage queue lengths
  • Decentralize decision-making
  • Apply cadence, synchronize with cross-domain planning
  • Unlock the intrinsic motivation of knowledge workers

Compliance meets Agile Development

In regulated environments, we usually talk about quality, safety, security, efficacy, specifications, milestones, verification and validation, inspections, audits, sign-offs, documented quality management systems, established processes, full traceability, Metrics – defects, requirements coverage, code coverage and more.
On the other hand, the foundation of Agile, the Agile Manifesto, identifies four fundamental value propositions:

  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.

Agile methods and regulated environments are often seen as fundamentally incompatible. One observed reason is a misinterpretation of the Agile Manifesto. Agile processes follow a logic in a plan-do-check-act (PDCA) cycle, whereby some development is planned and done, the results are inspected, and adaptations are made to improve the process to solve any problems that have arisen. In regulated environments, a defined logic is needed. Thus, the granularity at which development processes are expressed and adapted requires careful tailoring to the specific regulated environment. For example, some will require full traceability, some will not.

Compliance LogosRegulated domains exhibit varying levels of criticality, from safety-critical to security-critical. A core characteristic of regulated environments is the necessity to comply with formal standards, regulations, directives and guidance.There is a high number of regulations and standards which apply across different regulated domains. These are issued by a number of bodies or associations and/or region specifics (e.g., ISO, FDA CPT11, IEC62304, ISO 26262 …)

Software plays an increasingly important role in regulated environments. The principles of the agile manifesto were identified earlier, and although an overarching set of principles for regulated environments does not exist, a number of core issues for software development in regulated environments may be inferred. These issues include quality assurance, safety and security, effectiveness, traceability, and verification and validation. Taking this into consideration, we see that the various reference models used may differ a lot, but in the end, have a lot of similarities. In our opinion and through the experience of our product, Applied SAFe, to use agile in large scale and to fulfill regulatory requirements, companies have to address the following topics:

Quality: Have a Managed Process

  • Systematic and responsive quality management to enable a controlled professional process; in fact, establish an agile quality management system.
  • Establish Organizational Process Focus: Learn, innovate and improve
  • Reliability and correctness of product; e.g. with emergent design

Safety and Security: Transparency in Execution & Continuous Compliance

  • Responsive planning and risk management. to mitigate safety risks for users
  • Securely protect users from unintentional and malicious misuse

Effectiveness: Manage Process & Solution Variations, Reduce Waste and Do Exactly What is Needed

  • Satisfy user needs, and deliver high value to users with high usability
  • Do exactly what is needed with regard to solution to be built
  • Perform processes and procedures in accordance with their intended use
  • Build quality practices into process as part of the flow

Traceability: Ensure process & product compliance

  • Documentation providing auditable evidence of regulatory compliance and facilitating traceability and investigation of problems
  • Separation of process requirements and product requirements.

Verification and Validation: Engineering based on Principles & Practices

  • Embedded throughout the software development process (user requirements specification, functional specification, design specification, code review, unit tests, integration tests, requirements tests)
  • Product is specified, designed, built and tested in accordance with regulations

In subsequent blogs, we will lay out how these issues can be addressed. Based on our experience derived from Applied SAFe and together with our valued partners, we present the following lessons learned with scaled agile applications or mappings to various reference models.

Lessons learned

Most regulated requirements have a common background. A mapping of scaled agility to reference model is surprisingly straightforward, once the Lean-Agile mindset is understood. But there is also a catch which needs to be addressed: Mapping of compliance elements to value add deliverables! We have seen several times where requirements haven’t been interpreted but taken as simple facts, leading to a demand of unused, unnecessarily created artifacts. For example, in SAFe you are using a PI Planning board were dependencies and features are visualized, teams commit themselves to their own plans; it now would be a waste just to create additionally a Project WBS out of the prioritized items, just to fulfill the requirement of having a project schedule. Because compliance is often a ‘negotiation game’ between stakeholders & appraisers, it is natural that you have to deal with different mindsets and expectations based on past experience. We have also seen, that some reference models ask for process- and product-specific requirements.  Such requirements must be scoped for purpose and concepts and practices like Solution Intent and Agile Design Control needs to be established.

Compliance is best demonstrated in small iterations. It is a common mistake to ‘build in’ compliance at the end of development; this increases the ‘quality depth’ of a solution. It is far better to treat audits as a normal part of a system demo, e.g. defined as part of a ‘Definition of Done’ of a solution.

Compliance
The goal should be be to find real issues rather than to just achieve approval; i.e. to focus on the outcomes of an audit. Automated mechanisms to prove a mapping to a reference model greatly help to reduce discussion time and interpretation games between practitioners and assessors. Commercial frameworks such as SAFe are an excellent starting point to be applied in the development of high assurance systems.

In our experience, a mapping of the Scaled Agile Framework to various requirements of regulated environments and reference models is achievable within a lower number of weeks, once Lean-Agile principles and reference model have been understood. Depending on the attributes of a solution to be build or on existing documentation of a solution the form of ‘DoD’s can vary signiicantly.

The quality of a process model is of extreme importance. Only necessary steps should be modelled in the process and the processes
Process Model
need to build and rely on usage heuristics. A success pattern for us is the separation of ‘What shall be done’ from ‘How something is done’. The how something is done is described in practices and it needs to be ensured that practices can easily be changed/selected by performers.

An easily accessible and easy to use Quality Management System (QMS) greatly helps to get people on track with SAFe. A static representation of the process in the form of a wiki might work as a beginning; but for the long run, teams should be enabled to instantiate and customize their process for their endeavor specific requirements in order to reduce waste. A ‘One size fits all’-Process will almost certainly be too heavy and it is not a wise thing to impose unnecessary work on knowledge workers. The organization needed to maintain the QMS (e.g. a ‘Lean Agile Center of Excellence) also needs to work in an agile manner and enable fast process changes and piloting in appropriate SAFe-levels. We have learned that it is far better to let the responsible person (e.g. the Release Train Engineer for a program) perform the tailoring of their endeavor specific process in a controlled and easy way. Just trust that they will do it well!

Conclusion

Scaled Agility can be successfully applied in regulated environments!

Most available frameworks, especially SAFe, have most of the hooks needed for compliance with high assurance systems. As regulated requirements have a common background, it becomes possible to build a process model which already has most of the content necessary to fulfill those requirements. A tailoring of processes is a must to reflect applicable regulations as not all regulations are as stringent as others. Usually, the regulations do not imply how something shall be done. Companies should use this given freedom and map agile practices to regulations; agile practices like for example: ‘Build the solution incrementally’, ‘Apply fast learning cycles’, ‘Apply objectives milestones’, ‘Demo frequently; routinely deliver objective progress, product, and process metrics’, ‘Organize around value’, ‘Build quality in’, ‘Apply continuous verification and validation’, ‘Include compliance concerns in Definition of Done’, ‘Solution intent as concept for requirements’,  ‘Inspect & Adapt’, etc.

Build your own internal team of Lean Agile Center of Excellence (LACE) and establish a managed process and Quality Management System (QMS). Don’t forget to address live cycle concerns of solutions (e.g. live time & criticality). It is necessary to read and understand the regulations! Strive to map existing agile behavior and don’t impose unnecessary work in your processes.

Last but not least: It is absolutely key to include the executive level in the cultural change. They are ultimately those responsible and need to lead the change, and it won’t be an easy job. To achieve this, we strongly recommend to define governance and responsibilities, also on an Enterprise level and of course: to exchange your experiences with others!

If you want to learn more about an application of scaled agility in regulated environments, please visit www.appliedSAFe.com. In subsequent blogs, the author will discuss in depth how to address the specific topics discussed above.

The author, Peter Pedross, can be reached at peter.pedross@pedco.eu. Twitter: @AppliedSAFE


One of the most common problems with existing well-established agile teams is that they have issues delivering value-added user stories. The team is cross-functional, has established velocity, understands roles, process and cadences. But when is comes to demonstrating the work at the end of the sprint or program increment, the value behind what they develop falls short to the eyes of business owner, product manager or different stakeholders.

Most agile change agents or coaches have seen this scenario before and we all know it is neither the team nor the agile processes. It comes down to alignment and understanding of the work being committed during a sprint or program increment. The work the team has committed to in a sprint must have alignment to the enterprise, organizational or program goals. The team, leadership and stakeholders must all be aligned on the objective of the work and how that work will provide value back to the organization. In coordination with that, there must be a common understanding of the work being committed to by all parties involved. Lack of understanding leads to development of work that does not align to the value or goals we are trying to archive.

As a result of a lack of alignment and understanding there are four core problems that arise at the team level,

  1. Teams are delivering user stories which add no value to the enterprise or organization
  2. Teams are committing to user stories that are complex and large which result in an inability to deliver
  3. Team does not understand what they are trying to achieve with the user story
  4. Completed user stories are not demonstrable

As a result of seeing these common problems too often in my agile coaching experience, I have established the “Rubix Cube to Value Added User Stories”. This blog reviews the foundation, guiding principles and process which make this approach effective in ensuring that an agile team produces valuable user stories.

Foundation to Rubix Cube – Alignment and Understanding

The Rubix Cube is a perfect symbol to help demonstrate how user stories must be aligned and understood in order to ensure successful delivery of valuable user stories. Without the understanding and alignment of the work from the end users to the team, the team is being set up for failure.

As a result, we have set up a three-tier scope decomposition which originates from the Scale Agile FrameworkTM – a decomposition of work from Strategic Themes, Epic, Features and User stories. This framework is ideal for large scaled enterprises and can be scaled up or down, as needed, to fit any size organization. But a three-tiered system is best to illustrate the value alignment through the decomposition of work back to strategic themes and down to user stories. The key to scaling up or down this approach is to ensure that there is alignment from the top to the bottom of the framework, regardless of number of tiers.

To ensure alignment across our Rubix Cube, we should consider three key characteristics of each piece of scope that is critical to ensure we have a complete understanding of the work.

  • Details – Clear description of the “what” and “ Known How’s” of the piece of work. Identification of In Scope, Out of Scope, assumptions and Non‑Functional Requirements help to articulate the work.
  • Benefits – Identify the value behind the work based on three categories,
    • People – Who is benefiting from achieving this work and why?
    • Process – What is the benefit behind the process being enhanced?
    • Capability – What is the benefit behind the business or technical capability being enhanced?
  • Validation – Explanation of how the team, product owner, and other stakeholders will know that the work is complete. Details here can lead to acceptance criteria, Test Cases, etc.

Classification of the work into these categories becomes an effective and efficient way to get alignment and understanding of the work across all stakeholders.

This seems complex to complete and almost as painful as actually completing a rubix cube!  Ensuring there is full alignment and understanding of work across multiple incentives and teams is very difficult. This is why, in the days of waterfall, teams created 709 pages of requirements that would take four months to complete and required signed off by every person possible and baselined so that we ensure alignment and understand of this perfect rubix cube.  But today we can’t do that because market needs change too often and we can’t get the full rubix cube correct as it take too long to complete and the colors keep changing. The question is, what if we just want one side of the rubix cube to be perfect.  What can we do to line up the colors for one side?

Rubix Cube

We are about to move into the principles and processes which will lead us to value-based user stories. Remember that we are not trying to figure out the whole rubix cube, which is impossible in today’s world. The principles and processes below will help to outline how we constantly iterate, collaborate and refine the work so that we can get alignment and understanding for one side of the rubix cube long enough for the team to commit and deliver value.

Guiding Principles to Value Added User Stories

Knowing that we have a structure and foundation to document the work, we needed to establish some guiding principles to drive the alignment and understanding of the work. The guiding principles are all to drive a mindset of continuous iterations of scope decomposition to drive quicker value back to the organization.  

  • Align – Align all work to benefits. The core of this entire approach is alignment to value. The value derives from the benefits the scope is trying to achieve. Value should be identified at the highest level of scope decomposition and then aligned to the lowest leel. Establishing new or decomposition of value at lower levels Align Puzzle Piecesof refinement can lead to misalignment of work and non value added user stories. If, through refinement, new value is identified, it must relate back to an Epic (or highest level of scope decomposition). This could lead to adding it to or establishing a new Epic, which is specific to achieving that piece of value.  Doing this will minimize the risk of gold plating and keep the work aligned to value as it was intended.
  • Ensure – Validate that the work can be achieved by ensuring there is an understanding of the work Alignment to valueacross all stakeholders. Ensure they understand the value that will be achieved after the work is complete. This is how the value is realized. In the process, we identify value by the value to people, process and capability. Validation of that value occurs in the form of people, processes and capability to ensure the value was achieved. Doing this at every level of the scope decomposition ensures that work stays aligned to the value achieved.
  • Demo– Ensure pieces of work are demonstrated as minimal viable product. Sprint or PI Demo are the hardest of the agile process to fully achieve because it comes as an afterthought. Mid Sprint the team suddenly remembers that “we have to demonstrate something….” so they pull together whatever they can and hope it works at the demo.  For demos to be effective, thinking of what pieces of work tied together can be demonstrated at all levels of scope decomposition is critical. Splitting a single Epic into two demonstrable pieces of value allows for easier prioritization, better understanding, effective execution and value added demonstrations. Consider demonstrations when breaking down work.Demo


Process to Value User stories

The process outlined below is not linear and is very iterative. Think back to being a kid working on that rubix cube: If you kept at it for hours, it would eventually aggravate you enough that you would throw it across the room!!  Do not let that happen here. Start writing, have a conversation with someone (get their feedback), revise it, and then step back and see where you are. Then attack it again. It took my whole family an entire summer to get the rubix cube perfect. Don’t expect to lock down scope in a day and throw it over the wall. It takes multiple iterations to get it right.

Below is more detail about the process.

  • Write – Get the information down on paper. The culture of meetings and discussion too often creates more confusion than clarity when it comes to alignment of scope and decisions. Verbal communication can lead to misunderstand if not framed properly. As a best practice, write and allow enough time for people to read, react and ask questions. This aligns to the 3Cs in user story writing. Ensure the card is established first so that there can be an effective conversation which lead to confirmation.
  • Revise – Do not be afraid to adjust and create new Epics, Features or User Stories. Do not think of this as a traditional work breakdown structure.  At the core it may feel like it, but the principles and process enable iterations of determining the right scope. Feedback and conversation between the different levels of scope also helps to articulate the scope and validate true minimal valuable products. The management of these backlogs is an active discussion from top to bottom until the time of commitment at the team level.
  • Reflect –This rubix cube can get tricky as Epics and Features start to get split into 2 or 3 different Epics and Features. There are two key pieces to reflect on to ensure everything is staying aligned. First look across the features details to see if all major pieces of work are lining up to the proper sub pieces. Next ensure that when each piece Is complete is validated the benefits of the macro piece of work. This is critical to help ensure alignment. Constantly reflect and adapt to ensure the sum of the breakdown of work achieves the whole.

Call to Action

In my experience, I have seen teams and groups of teams called failures because they were unable to deliver value added user stories. This was not because the team was not effective or did not have the proper skill sets, it was because the team was unable to get alignment and a full understanding of the work.

In today’s environment, this is becoming the norm. The rubix cube approach to value added user stories helps to manage this unknown by ensuring that work is aligned to value and understood before it is committed to. It also helps to establish an iterative approach to scope refinement. If you are having challenges with delivering value added user stories, I ask you to try it, provide me feedback and improve the process.


Scaled Agile Framework (SAFeTM) change agents often face similar challenges when trying to implement SAFeTM within an organization. Change agent is a person from inside or outside an organization, which is driving a transformation for an organization. Change agents also have useful and creative tools and techniques in their toolkit to try to drive this change within the organization. However, many times transformations fall short.

Why does this happen?

As SAFe change agents, we need to reorganize and repurpose our toolkits to ensure that our tools and techniques for implementing SAFe clearly adhere to the SAFe principles and core values.

Scaled Agile transformations are really hard.

They are massively complex, have significant unknowns, and leaders typically expect results now!  On top of that, with SAFe transformation comes the need for a dramatic culture shift within the organization.  As a result of this complexity, there are several approaches to implementing SAFe within an organization. But ultimately, the value takes too long to achieve, the uncertainty around culture changes become unmanageable and the transformation loses momentum.

Does this sound familiar? The particular issues that arise when implementing SAFe are some of the same challenges that drive organizations to want to adopt SAFe in the first place: the value of a product takes too long to get to the end consumer, requirements and consumer needs change at an unmanageable pace and the teams lose motivation.

So, if they have similar challenges, can’t they be solved by the same solution? Assuming yes, why not solve transformation challenges by leading the transformation with SAFe principles and values?

There are five concepts from the SAFe principles and values that are critical to ensuring a successful SAFe transformation.  By using these concepts, an organization can set its vision for the change, consistently inspecting and adapting yet getting quick value added wins, and is able to set a foundation for continuous improvement.

Build a Cross Functional Transformation Team

Building a coalition for change is critical to any transformation.  When working to put together a transformation team to lead this change, consider what makes up a quality scrum team.  Cross-functional teams are the best type of scrum teams as members can make decisions and work through dependencies within the team.  So, a scrum team should have developers, testers, user experience experts, hardware, software, etc., so the team can build business value systems within the team.

With a team leading a transformation, the approach needs to be similar: i.e. assemble teams made up of members from all impacted areas of the change – business owners, program / project managers, software developers, infrastructure, human resource and a representative from every area that may be impacted.  The key is to have a team with a wide enough perspective to help drive the change and deliver consistent messaging and processes across all areas. This will help to manage the variability in the messaging of the change.

Also, training is critical to ensure the team marches to the same beat. Every member of this transformation team must become a SAFe educated change agent in the organization to help drive the culture change across all layers/areas of the organization.  While speed of change is important, we must spend a substantial amount of time on training to build a solid foundation for the transformation.  If solid training of the core values and principles of SAFe is not implemented early, when the transformation team starts to drive change, they will fall flat in the organization. This is when you observe organizations doing the motions of agile rather than living the behaviors of strong agile values.  Remember to spend time on training, leading agile thinkers and change leaders, to build that solid foundation upon which to move the transformation forward.

Visualize a Transformation Roadmap and Vision

Humans do not do things just for the sake of doing. We all have intrinsic motivation that drives us to change. In a transformation we demand a lot of our organization and team members.  The transformation team must build up such intrinsic motivation for team members to change.  Within SAFe, we achieve this goal by aligning the scrum team’s backlogs to strategic themes, vision and roadmaps.  Theme, visions and roadmap should also set the context around why the organization needs to change, what are the opportunities and proposed solutions that are going to make the organization better. This gives the teams a context for the work and shows them how the work they are doing provides value back to the organization.

In a similar way, we must provide the context as to why we are taking part in specific agile ceremonies or changes in culture.  People may see these changes as a waste of time or an attack on them personally, which often results in a negative reaction.  People need to understand where they fit and even if they are apart of the to be motivated to fight with and not against the change. But if the context around the ceremony or process is presented, we can build up that intrinsic motivation and encourage a deeper engagement. Without this context, team members will just go through the motions without getting the true value. The key is unlocking that intrinsic motivation: it will enable the value to emerge behind those changes and build positive reactions toward the changes.

Daily Scrum Example:
  • Without intrinsic motivation behind change: If a team member is simply asked to go to the daily scrum, they will show up, give quick answers and move on with their day.
  • With intrinsic motivation behind change: The team member comes empower to social decisions made within team and address any blockers that need resolution.

The following are four steps that can help visualize the vision and roadmap to unlock the intrinsic motivation of team members:

  1. Establish a Vision – After initial training of the transformation team, set some time to establish a vision and context for change. Establish the leading drivers for the change, e.g. faster time to market, high quality, etc.
  2. Build a backlog of opportunities – The backlog should contain a specific set of tangible challenges within the current state of delivery in the organization. This helps make the changes real and relatable.  The benefits behind the changes become tangible.
  3. Refine the backlog – The refinement process within the SAFe framework helps to reduce complexity and ambiguity around the work at hand. Refining the backlog of opportunities will reap the same benefits for the transformation, as it will help align opportunities around the value to the organization.
  4. Establish a roadmap – The backlog may seem intangible due to its size or complexity. Understand that a transformation does not happen overnight or over a period of weeks. Establish a six to twelve month rolling roadmap to help manage the amount of change as well as work in progress.

Take a Systems View When Planning

When taking a systems view in the Scaled Agile Framework we arrange backlogs to enable system development of business value over technical component development. A system can be an end-to-end solution, a set of people and a process to build an enterprise or a value stream to an end consumer. A system is only as good as it weakest link so a weak component within the system will tend to drive down the value of the stronger components and therefor hinder the value to the end consumer. The value behind a system is the cross functional slivers of value to the customer. Think of the 7-layer cake analogy, one bad layer and the whole cake is ruined, but if the layers are blended together it is culinary bliss.  Without taking a systems approach to planning of the work, the value will always be bottlenecked by the weakest component to the end user.

The same thought process must be taken when looking at a transformation with the Scaled Agile Framework.  SAFe is a system in itself and, like any system, if it has weak links, it will fail to provide its maximum intended value.  When looking at the backlog of items for a transformation, it is critical to align opportunities around value to the organization.  This ensures that as the framework is being integrated in the organization, it is built to maximize value in the system rather than create a weak link in the system.  Below is an example of a value added SAFe System and a weak link SAFe System.

Value Added SAFe System: Implementing Kanban refinement processes at the Portfolio, Program and Team level which all align to the strategic themes of the enterprise.

Weak Link SAFe System: Performing a full PI Planning event without conducting an Inspect and Adapt workshop to learn from opportunities that arose.

This approach becomes critical to establish early wins in your transformation.  When the transformation takes a systems approach, it provides value directly back to the organization, and any external stakeholder or agile naysayer in the organization will begin to see the light and positives of this approach.  When we fail to take this approach, the door is left open for agile naysayers to latch on to the fact that the value is not achieved due to the weak links in the system. Implementing SAFe with systems thinking in mind will aid in getting support and changing those naysayers into change agents.

Take an Economic View of Prioritization

Taking an economic view when implementing in Scaled Agile framework, demands that we ensure maximum business value is delivered in the shortest about of time. Therefore time to market is essential and prioritizing backlog items based on those criteria is critical.

With SAFe transformations, the factor of time is the amount of cultural change that has to take place to implement the change.  Transformations often experience severe delays or halt completely because of an organization’s inability to change the culture in a timely manner.  Similar to SAFe, when looking at the transformation backlog, time should be factored in as the amount of cultural change a specific item should take over another.  Implementing a change with minimal cultural change may become a quick agile win over trying to implement something that requires a significant amount of cultural change to overcome.  This becomes critical to the SAFe Transformation providing business value.

An economic view translates into a review of the backlog for items, which would provide the most value and most significant progress in the shortest amount of time.  Within the SAFe model, using the formula for Weighted Shorted Job First (WSJF) does this.  This formula helps to identify the return on investment upon doing one piece of work over another with the primary focus around Cost of Delay (COD).  It compares the COD relative to job size for a subset of the backlog.  This formula should be used for the transformation backlog with some modifications.  For transformations, the WSJF should be calculated as Value to Organization, Time Criticality, and Risk Reduction/Opportunity Enablement relative to the Degree of Cultural Change.

 

 

Since the largest blocker to any transformation is cultural change, it is critical to evaluate this factor when prioritizing. Let’s take two examples to show this,

  1. As a part of a transformation there may be significant value in establishing the Product Owner role with someone from the Business. This would ensure work is aligned to business value.  But in this company the business is an entirely different organization than IT, thus forcing them to establish a Product Owner role would be a giant culture change.  Using the transformation WSJF this would score fairly low due to the high impact of the degree of cultural change.
  2. On the other hand, establishing daily scrums and the scrum of scrum practices within an organization, which already has scrum master in place, would be a high transformation WSJF. This change has value to the organization, high-risk reduction and a low degree of cultural change.

Transform on a Cadence

The complexity behind software development is due to the unknown and variability in development. Technologies change, dependencies evolve and requirements change quicker than ever.  With a SAFe Transformation, similar unknowns and variability will occur around the amount a change an organization is willing to take on at once.  People have a tolerance limit to change and in general many people are change adverse.  In any given situation within an organization the amount of change an organization can vary based upon that organization and a given situation.  Several factors out of the control of the transformation team will limit the amount of change an organization is willing to handle.  As a result, a transformation should be conducted on a program increment and iteration cadence.  This would include having PI Planning, Iteration Planning, Stand Ups and Inspect and Adapt workshops as a minimal viable product.  The purpose of this is control and managing work in process, inspect and adapt on complete transformation work, and line up future work, based on value.  A description of how each of the ceremonies should be run to gain this purpose is shown below.

Transformation PI Planning – All members of the transformation team and key sponsors attend.  A half day meeting where the vision and roadmap is updated. The outcomes should be a determination of any major milestones, an updated vision and roadmap, commitment of backlog items and resolution of any critical barriers. The team should establish measurements of success of the program increment and commit to their work around those measurements.

Transformation Sprint Planning – Conducted every two weeks with the entire transformation team.  Each meeting should last no more than one hour.  Outcomes of the meeting include resolving any upcoming issues, monitoring change tolerance, and committing work for the next 2 weeks.

Transformation Stand-Up – Occurs 2 to 3 times a week and follows typical standup ceremonies across the transformation team.

Inspect and Adapt – Conducted every two weeks focusing on the progress made, lessons learned, updating of future backlog items.

Transforming on a cadence allows for constant commitment to change as well as constant feedback.  It also creates a sense of urgency around the change, which the transformation team, and rest of the organization, can feel and build on throughout the transformation.

Empowering Changing Agents

At the begin of this journey, I discussed the need for SAFe change agents to reorganize and repurpose their toolkits to transformations with more SAFe values and principles. I have outlined some of my modifications to my toolkit to be better aligned to SAFe principles and values.   My hope is that you, as SAFe change agents and leading agile thinkers and organizational leaders, are now empowered to reflect on how you are transforming your organization and ask are we following SAFe principles and values during your transformation.

  • Do you have a properly trained transformation team to lead this change?
  • Is your Transformation roadmap and vision clear and understood?
  • Are you taking a systems view to planning your transformation?
  • Does prioritization of your transformation backlog occur with an economic view?
  • Are you driving your transformation in a scrum like fashion?

If no to any of these, take time to reflect and take action to allow your transformation to be better aligned to SAFe principles and values.

If yes to all these, than I challenge you to keep true to the SAFe principles and values and look for continuous improvement.

_________________________________________________________

Dan Teixeira is currently an Agile Change Agent for Blue Agility, helping lead organizations from team level to portfolio transformation to optimize delivery of business value. Dan brings his expertise in Agile/Lean best practices and industry experiences to help teams deliver the right results, faster and with higher quality. Dan is passionate about shepherding organizational change management across all levels of the enterprise by empowering people with new and innovative ways to view problems and solve challenges. He strives to bring meaningful new approaches into organizations to ultimately improve the lives of people.

 


The As-Is DevOps Value Stream Mapping

Value Stream Mapping is a crucial step in assessing an organization’s DevOps capability. The objective of mapping a DevOps value stream is to eliminate wasteful waiting and improve the completeness and accuracy of all activities in the value stream. We create a value stream map of the software development lifecycle early in any DevOps engagement.

To understand and expose those wastes and inaccuracies, the first step is, naturally, to map the as-is state of your organization’s software development and operations.  Such mapping typically starts with a two-day session involving business and IT staff to capture the major activities involved in software development and operations.  The figure below shows an example of a value stream map (VSM) of as-is DevOps activities.

Legend:
%C/A: For a given VSM step, this is the percent of Complete/Accurate work items received from the previous step in the VSM.
LT: Lead Time for a given VSM step, i.e. from the instance a work item leaves the previous step to the instance it leaves this step towards the next step.  LT includes both idle time as well as time during which the item is being productively processed.
VA: Value Added Time, which is only the time during which the item is being productively processed.
Determining the above metrics in the as-is map will guide the desired improvements later when mapping the to-be DevOps process.

The following are the type of questions that would help a group of business and IT staff convene to produce an as-is DevOps VSM. The questions are not meant to be walked-through in strict order, but can be navigated back-and-forth in the session of drawing the as-is VSM.

  1. What are the main steps involved in the current process of software development and operations? We need to look at the factors that determine the boundaries between those steps, including handoffs, queues, and organizational stipulation.
  2. Who performs each step? Include role names and names of some of the specific people who perform the step.
  3. What is the %C/A for each step? For each step in the Value Stream Map, capture the percentage of work items that arrive at the step being complete and accurate. To get a realistically representative value of this metric, you may have to capture an average of it over several weeks, or even several months.
  4. What is the LT for each step? As with all metrics of Value Stream Mapping, to get a realistically representative value of this metric, you may have to capture an average of it over several weeks, or even several months.
  5. What is the VA time for each step? The VA excludes waiting time (e.g. being on a queue) or any other non-productive time experienced by the work item.
  6. What tools do you currently use for each step? Answering this question would help uncover manual steps that can be automated, determine opportunities for integrating various tools, and improve efficiency and accuracy of automated steps.

The To-Be DevOps VSM

Once you have the as-is DevOps VSM mapped, the to-be DevOps VSM is driven by the following:

  • How can we significantly increase the %C/A for each activity in our as-is VSM?
  • How can we dramatically reduce, or even eliminate the non-productive time in the LT of each as-is activity?
  • How can we improve the performance of the VA in each as-is activity?

Answering the above questions can lead to drawing a new, to-be VSM with realistic, but sufficiently challenging, new targets for each of the above three metrics: %C/A, LT, and VA for each activity in the new, to-be VSM.  Such to-be VSM will usually encompass activities that do not correspond 1-to-1 with the activities on the as-is VSM.  The following is an example of such to-be DevOps VSM:

Mapping Your DevOps Value Stream

Our Blue Agility DevOps coaches can help your organization with:

  • Guidance for detailed answers of the above listed questions for drawing the as-is DevOps VSM.
  • Templates for capturing comprehensive information for each as-is / to-be activity.
  • Assessment to determine which of the activities shown in the above to-be example VSM are suitable for your organization.

_________________________________________________________
Ali is a senior consultant at Blue Agility. He performs strategic services to key customers in order to accelerate achievement of business goals by leveraging the benefits of process mentoring and automation through tight integration with business critical processes. He works with customers to identify the Key Performance Indicators (KPIs) that are critical to business success. He is SPC4 certified. 


PHILADELPHIA, PA – September 1, 2016 – Blue Agility today announced that is has been awarded a one-year contract, with extension options that could make it a total of five, to assist Sandia National Laboratories, Division 5000, Defense Systems & Assessments, in transforming their software development lifecycle to an Agile methodology. Under this contract, Blue Agility will be offering Sandia a variety of services such as Agile Training and Agile Transformation Mentoring and Coaching, including Scaled Agile Framework (SAFe) initiatives. The contract was awarded to Blue Agility based on a competitive bid process. The firm’s services will aid in Division 5000’s vision to transform research into game changing solutions that provide the warfighter and intelligence community with unmatched superiority. Work will be performed primarily in Albuquerque, NM.

Blue Agility management believes that its contract with Sandia will continue to strengthen Blue Agility’s leadership position in Agile Transformation and software development services.

“Being awarded this Sandia National Laboratories contract is an important milestone for our company,” said Eyal Abukasis, COO at Blue Agility. “This award highlight Blue Agility’s unique experience and capabilities in delivering large scale transformations and acknowledges our leadership position in the marketplace. We are pleased Sandia selected us to partner with them and look forward to supporting their mission to create key program efficiencies.”

About Sandia National Laboratories

Sandia National Laboratories is operated and managed by Sandia Corporation, a wholly owned subsidiary of Lockheed Martin Corporation. Sandia Corporation operates Sandia National Laboratories as a contractor for the U.S. Department of Energy’s National Nuclear Security Administration (NNSA) and supports numerous federal, state, and local government agencies, companies, and organizations.

About Blue Agility

Blue Agility specializes in large-scale Agile transformations leveraging the Scaled Agile Framework® (SAFe™) and Application Lifecycle Management (ALM) tools. Blue Agility provides a framework of people, process and technology, enabling the enterprise with continuous delivery capabilities. Leveraging our bluejazz™ knowledge platform (2015 Beacon Award), organizations access customized role-based tool usage models, ensuring scalable and sustainable enterprise-wide transformations with end-to-end traceability. www.blue-agility.com


Real World Coaching and Mentoring Expertise Combined with a Leading Knowledge Management Platform Bolster Client Success

Philadelphia, PA – August 17, 2016: Blue Agility, an industry leader in large-scale agile transformations and application lifecycle management (ALM) technology, and PEDCO, creators of Applied SAFe®, a fully-fledged ALM tool agnostic implementation of the Scaled Agile Framework® (SAFe®) as a process model, today announced a strategic partnership to help organizations accelerate and streamline the implementation of the Scaled Agile Framework (SAFeTM). The two industry-leading companies are teaming up to support the growing number of PEDCO’s Applied SAFe clients seeking to maximize the benefits of their large scale agile adoption. The synergy between Blue Agility’s expertise and proven track record with large and complex agile adoptions and PEDCO’s innovative product will enable their clients to customize the framework and tailor it to their industry and specific business context.

For large organizations in an increasingly competitive marketplace, moving from traditional waterfall software development processes to lean, agile and synchronized efforts bring the promise of improved quality, shortened time to value and increased client satisfaction. However, scaling those efforts from small teams to an enterprise level introduces myriad of challenges. It is at this point where clients need the support of an experienced coach backed by a leading process management platform. Together, Blue Agility and PEDCO provide the experience and technology to ensure a smooth and successful transition effort and significant return on investment.

“I’m excited about our strategic partnership with Blue Agility. Their experience with providing expert coaching and training services for large scale SAFe implementations significantly enhances PEDCO’s ability to ensure a seamless transition to agile, lean and compliant processes for the growing number of Applied SAFe clients,” said Peter Pedross, CEO at PEDCO.

“We truly understand the challenges faced by our clients when implementing SAFe, particularly for those operating in regulated industries. By working in partnership, PEDCO and Blue Agility are uniquely positioned to provide customized and comprehensive enterprise-ready solutions for organizations wanting to adapt SAFe to their context,” said Eyal Abukasis, Chief Operations Officer at Blue Agility. “With PEDCO’s Applied SAFe, the potential to smooth the path to a full SAFe adoption that ultimately translates to high business value and customer delight is substantial.”

About PEDCO
PEDCO – Managed Process Services is a public limited company based in Zurich, Switzerland and a collaboration partner with Scaled Agile Inc., Boulder (USA) and Method Park, Erlangen (Germany). PEDCO supports enterprises around the globe for process implementations for complex product lines or within regulatory environments. We offer a comprehensive range of solutions to set-up, select, operate, and develop lean, compliant and efficient processes.

Applied SAFe® is a stand-alone product from PEDCO. It is a fully fledged ALM tool agnostic implementation of the Scaled Agile Framework (SAFe®) as a process model and kept in sync with the actual SAFe® version by Scaled Agile Inc. (SAI). It serves as your own comprehensive, customizable and tailored instance of SAFe®. Together with our Applied SAFe Consulting Partners, we ensure a smooth transition to agile, lean, efficient and compliant processes. www.AppliedSAFe.com.

About Blue Agility
Blue Agility specializes in large-scale Agile transformations leveraging the Scaled Agile Framework® (SAFe™) and Application Lifecycle Management (ALM) tools. Blue Agility provides a framework of people, process and technology, enabling the enterprise with continuous delivery capabilities. Leveraging our bluejazz™ knowledge platform (2015 Beacon Award), organizations access customized role-based tool usage models, ensuring scalable and sustainable enterprise-wide transformations with end-to-end traceability. www.blue-agility.com


Whom Do you Seek?

A major key to success of a sustainable agile transformation is finding the right person or persons to lead the transformation. This person(s) need great prior experience at the Enterprise level coaching and mentoring as a ‘Sherpa guide” through the difficulties of an Enterprise wide agile transformation. This is an “OZish” view of the behind the scenes of how an agile adoption can proceed, leadership and its role and the case for the “determined person”.

Follow the Yellow Brick Road…

I often ask people who their favorite character is in the movie “The Wizard of OZ”. Usually it is Dorothy or the Scarecrow. Those that answer Toto. I worry about. My answer is “I like the Man Behind the Curtain”. Here is the actual wizard working the flash and bang of the big show from a small side stage and he does not mean to be seen or heard (other than through his avatar).

Man behind curtain

Good mentors are like that. Good Enterprise Transformation Coaches are very much like that. They project leadership and strong qualities, and work the invisible pedals and levers of the Transformation within your organization. A great coach or mentor is always taking a back seat to the Employee who leads the Transformation. Even though they may be for this one topic of Transformations “the smartest person in the room” they don’t act it. They work at drawing out people, providing behind the scenes coaching, salting the conversation with ideas that others can latch onto as their own.

If required, they have the strength of character and leadership capabilities to take charge, but as a least acceptable solution. The Enterprise Coach should get their sponsor and lead to step up to the role of leading the Transformation.

What Comprises a Set of Skills?

Defining the Enterprise Agile Transformation Coach role is a mix of:

  • Communicator (up and down the whole chain of command)
  • Agile experience and practices
  • Enterprise Transformation experience
  • Technology savvy across multiple knowledge domains
  • Business experience and savvy to connect with non-IT types
  • Exposure and experience across the IT organization

Basically, someone who has been there done that, built and burned down the T-Shirt factory a few times. So they must have had experience with Enterprise Transformations before. There is no replacement for experience in this realm.

Most important they have a force of will to drive to get things done. Many years ago I read a paper on the concept of “The Determined Person”. The basis of the story was that The Determined person is someone who, despite what seem to be overwhelming odds manages to persist through the effort to its conclusion. Someone of strong conviction and faith that we can solve problems and overcome inertia of culture. This strength of will is coupled with persistence. This persistence of vision from Calvin Coolidge is my favorite quote of all times.

“Nothing in this world can take the place of persistence. Talent will not: nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not: the world is full of educated derelicts. Persistence and determination alone are omnipotent.”

Do I Hire Someone Who is Certified?

Certifications are not a replacement for experience. I’ll take the seasoned veteran of the fight any time over someone with 5 certs on their resume. An interesting question to ask in an interview to sort out who is experienced is “So tell me about a major transformation failure and how did you get out of it?” An experienced coach will have interesting (and sometimes scary) stories for that one. (FYI, the more interesting part of the answer is how they got out of it).

TrekkersSomeone with little or no experience or who is too cautious to answer is likely not the kind of Mentor you are looking for. You want someone with wisdom, and unlike the catch phrase, “with age comes wisdom” it really should read with EXPERIENCE and failure comes wisdom.  Once you’ve had your metaphorical legs blown off by stepping on the various landmines strewn on the path to Transformation, you learn what a landmine is and how to avoid it. I want to follow that person.

These Coaches Are Really Expensive…

So I got one of these people lined up, now I can’t afford them. Yes, experience comes at a cost. The kinds of consulting we are discussing is expensive. Cheaping out just means you get what you pay for. Besides, transformations are cheaper with a good guide. Experienced coaches save you money by offering up, “I did this in three accounts, it worked in these two and failed here because… This kind of guidance can save lots of time, energy and money.

The value a Mentor brings is the experience and guidance to provide you with the capability to succeed. Just like climbers of Mount Everest hire Sherpas, you need to do the same.

I hope you’ve enjoyed and learned from our “Playing the Agile Transformation Game” Blog series. Did it answer some your questions? We’d love to hear from you…

And stay tuned for our upcoming blogs!


I’ve been working at doing Enterprise transformations for 18 years now and I can guarantee you that Murphy’s law is quite alive and well. Or as technologists know – the perversity of the universe is optimized toward the maximum. I do have to say all of these events are predictable, and with proper vigilance, can all be avoided. Now you just have to pay attention to find the ones I have not identified.

Here are lots of lessons learned from war stories of how large scale adoptions go off the rails with great ease.

“Left to themselves, things tend to go from bad to worse.” – Murphy’s First Corollary

Failure of the Agile Transformation Team to Deliver

So it turns out you have assembled the best team capable of delivering a new agile transformation to the organization. We have key representatives from all contributing departments; we have the best and brightest decision makers to get to right plans in place and we are ready to begin. We hold our first Transformation team meeting and we have a 70% or better “no show” rate because of press of business on the part of all these people who also have full time (as in 120% booked) day jobs.

Fallen chess pieces

This becomes a real failure upon the part of the Agile Transformation Team to deliver. The team consistently fails to meet; they consistently fail to deliver any assigned work as it is not as important as their day jobs. Essentially you get nothing done.

What happens to your well-conceived Agile Transformation is that you encounter the Second Law of Thermodynamics – and a state of entropy occurs. Your transformation dies a universal death.

Failure to Measure Against a Plan

Simple logic dictates plan the work, work the plan. This is a simple axiom to follow, yet it seems when we actually encounter the work, the plans go out the window. This always amazes me when professional project leaders dump logic and purpose for panic.

It seems that staff on the Agile Transformation Team are not aware we will fight battles, win some lose some, and as long as we win a majority and re-fight when we are in a stronger position for the others, we will ultimately win the war. Instead, each battle is assumed to be the war.

If the plan is no good, of course jettison the plan in favor of a better one. Just don’t proceed day to day without middle term and long term goals and objectives and a path to get there.

Measure progress forward and backward to the plan, use it to gauge and inspect and adapt to the vagaries of the workplace. As Dwight Eisenhower said “Plans are nothing, but Planning is essential”. Do contingency planning, have a Plan B, C, D and Z if necessary.

Failure to Communicate

“What We got here is a Failure to Communicate” – Strother Martin from “Cool Hand Luke”

Failure to communicate is often a cause for failure. Our goal is to establish an agile environment where Transparency and Trust are vital to the success of agile adoption and our transformation. Too often, due to the nature of trying to deliver “stuff” (“Stuff” is a technical term for anything we need that is support or infrastructure necessary to our cause) we miss the opportunity to shout from the rooftops the availability of “stuff” for teams to use to do their jobs.

Or we miss the opportunity to create celebration moments for highlighting successes. We do this for generating excitement and good will for the program. When was the last time you celebrated a success with the team? Get your leadership from both the IT and business sides to go to the team and congratulate them in front of their peers who may not yet be on agile teams. “Hey, look the boss is throwing a pizza party for the agile team, how do I get a pizza party?” That is what you want everyone NOT on an agile team to start thinking… then we can introduce them to agile.

road-sign-63983_1280
Communication Plans and Change Management plans ala Cotter or ADKAR as essential to the success of a transformation. Use every means at hand to communicate what’s happening. Especially WHY you are doing what you are doing. The WHY is just as important as the HOW and the WHAT.

Failure to Lead

I once read an article that dealt with the topic of “the determined person” and how that person would use their talents to overcome any obstacle placed before them. I view agile transformations at the enterprise level to fit that category of “any obstacle”. Lots of barriers, cultural roadblocks, technical traps and management indifference await the determined person who will now need to overcome these barriers.

These types of barriers and more are already in place and awaiting you to be challenged. If you fail to provide leadership and the ability to lead by example, how can you expect that your Agile Transformation Team will follow you? All these barriers, challenges and obstacles will require your best every day to overcome them.

“Everything will go wrong at once” – A Modern Revisionist’s Murphy’s Law

Thinking Too Small

Agile Transformations for very large organizations (2000 staff and up) can take years. Don’t get caught without a strategic plan to accomplish growth over time. Your timeline could look something like:

  • 1 – 6 months Organize, Mobilize and plan the whole effort
  • 4 months to end of year 1 – Early Adopter and piloting
  • 1 year – 3 years Bulk of the adoption based upon organization size and complexity
  • 1 year and on – Establishing stability of the conversion

Don’t get caught thinking that for very large organizations, you will get this done in a year. If you can and do, maybe you belong with the Justice League saving the universe.

Organically Growing Due to Lack Of Management Education

This is a result of abandoning planning. You are just moving from one shiny object to another based on management whim. As an agile Transformation team, you need to broadcast and syndicate support for a plan across the board. Make it public and work the plan. Having a rolling 4 quarter plan that accommodates change is fine. Just keep it in front of everyone so there are no gotchas.

Little or No Change Management Capabilities

Key messaging and managing expectations are keys to success for these Enterprise Transformatons. You have to let everyone in the division know what’s happening, when they may be part of an agile team, what the expectations are, what training they will receive, that coaches are available… you get the idea. Spew information like Linda Blair in the exorcist spewed pea soup all over the priest. If the staff start telling you “too much Information,” you’re doing your job well.

Failure to Get Bottom Up Support for Your Efforts

This is a variation on a theme of the Failure to communicate problem. Actively solicit your teams to speak with leadership; have them tell their stories to their peers. Ask them to sponsor communities of interest for various aspects of agile practice. Work the teams to tell their stories and talk with their peers. This is much more powerful than you think.

“It is impossible to make things foolproof, because fools are ingenious” – Murphy’s second Corollary

Failure to Keep Your Ear To The Ground To Help Avoid External Events Like Poor Business Performance Terminating Your Budget

This happened recently to a company I know of. A downturn in business caused severe budget cuts in the IT area (as well as companywide cuts). End result is many of the Agile Coaching and Enterprise Transformation staff got cut. This caused a loss of capability to achieve forward motion. Agile Transformations can be very expensive, and therefore are a potential target for budget cuts.

One shop I worked in had invested $18.5 Mil in a transformation, they were acquired and the acquiring company having just come out of a bankruptcy had a mentality that “if it does not make us a penny today, don’t do it” The $28.5 Mil investment in the Transformation was scrapped. Keep your ears open for events like this. Even public companies can show signs of upcoming bad news. How would you prepare for a downsized Agile Transformation so you can keep it alive?

Loss of A Key Sponsor

It has happened to me three times now in 22 shops. One heart attack, two changes in management for reasons I cannot mention. The losses were sudden, and new replacements essentially meant new direction too. There was always some period where the new sponsor undertook to come up to speed so as not to rock the boat initially, but in all three cases, the new CIO wanted to prove something to their superiors, that they could get more done with less.

This put a large target on any efforts that were not directly contributing to the business, and unless your transformation is well documented, has serious success stories, has won the hearts and minds of the new CIOs senior staff and is well entrenched as a “good thing” for the business, you should be checking out alternate business opportunities within or outside of the company because your future as the lead of the Agile Transformation team is a short term thing.

Backsliding or Just Plain Failure of Teams to Adopt

My experience says adopting agile is not that hard. Almost all teams properly mobilized and organized can practice agile as SCRUM or KANBAN. So if you are encountering failure to launch, or serious backsliding, check the competence of your coaches, evaluate the competence and effectiveness of your training materials, question the veracity of your competence surveys before you blame the teams. Something in your delivery mechanism is broken. Look internally first, before you blame the teams.

Missing Overcoming the FUD Factor

FUD – Fear Uncertainty and Doubt. Having teams overcome the FUD factor when adopting agile is very important. If they never get over it, that team will be a failure. The FUD Factor is not hard to discover. You can actually see it in the faces of the team members who just don’t get it, or those who see their current job description being disintegrated before their eyes. Having the successes to point at, having leadership address the change in methods and that all are still valued under the new ways are good ways to address this problem.

So there you have it, the challenges, the pitfalls, the problems, the landlines, and Murphy. But don’t despair… Just be prepared!

Get ready for our next and last blog coming soon.


Overview

“Donkey: Are we there yet?
Shrek: No
Donkey: Are we there yet?
Fiona: No, not yet!
Donkey: Are we there yet?
Shrek: Yes!
Donkey: Really?
Shrek: No!!!!”
From Shrek-The Movie

Measuring an agile transformation effort is what we are looking at today. Several important questions present themselves about measures: What to measure? How to Measure? When to measure? Who to report it to? All good questions to help us determine two crucial things:

  • Are we there yet?
  • Are we sustaining the effort?

So here are some Tips and Tricks to picking the right metrics to provide management and record the journey and the capability of sustainability. We can help define this journey by determining when you hit the “Critical Mass” that is, when the transformation starts clicking over on its own.

To define the critical mass, I think there are three valuable metrics:

  • Conversion Rate
  • Hygien
  • Customer Satisfaction

These three metrics help us understand are we there yet, if we’ve reached critical mass and if we are delivering value to the business customer.

What is Critical Mass?

At a point in time, your transformation all of a sudden takes on a life of its own, and the transformation is suddenly less of an uphill trudge and more of an enjoyable experience. What happens is that you reach a “Critical Mass” in conversion. There are more staff educated and using agile techniques than are not.

I borrow the term “Critical Mass” from nuclear technology to represent the phase a nuclear reactor achieves when a just enough sufficient amount of nuclear fissile material is brought together and a chain reaction (the giving off of electrons) takes place within the fissile material. This reaction is then controlled using graphite rods to keep the reaction going at a controlled pace.

Like the nuclear reaction, there is a point in the transformation where we achieve critical mass and we have enough going on that we find the effort is easier than before.

  • Enough staff are educated on agile methods
  • Enough staff are working on agile teams producing valuable software for their customers
  • Enough of the leadership on both the technology and business branches see the value of what we are doing.

Measure the Results of the Transformation

The Conversion Metrics

So we are faced with determining how many and when with regard to the staff in our organization. How do we track their agile journey? Some simple metrics help.

Let’s track two simple metrics:

  • Their participation in agile training
  • Their participation on agile team(s)

Topography - MeasurementThese two simple metrics can be tracked in an inventory of all staff in a division or Information Management department. This gives us the view of how much of the IT unit we have converted. At some point when a minority to majority are converted, that Critical Mass event will take place. I’ve seen it happen as early as 25% conversion and in some very slow organizations as late as 75% conversion. When the event takes place has much to do with the prevailing culture of the organization. Culture and its effect on your agile transformation is a whole different conversation for another time.

FYI, don’t forget to include training management and leadership and recording their compliance too!

Hygiene metrics

When launching new agile teams, we need to be able to determine at some point after they are separated from coaching and mentoring whether or not they are practicing good hygiene regarding the use of the ceremonies, practices, principles and tools.

This can be as simple as the practice of doing self-assessment surveys at regular intervals. I like the idea of once a quarter self-assessment that list three point of view: the team as individuals, the Scrum Master and the Mentor or coach – optionally the Product Owner may also have a separate opportunity to vote on the same categories.

Categories are simple:

  • The Agile Ceremonies
  • Practices
  • Tool Usage

A simple 1 – 5 scale works and a spreadsheet tool is very commonly used. Results are often mapped as spider diagrams like the one below. You define questions around the usage of agile practices and tools and then ask the team to take the survey. Compile the results and publish them for use in a retrospective.

Team Maturity Assessment

Figure 1. Team Maturity Assessment

Don’t forget converting Leadership as a measure of success!

Customer Satisfaction

Are we delivering Valuable Working Software? Measures for valuable software in the customer’s hands could be:

  • Quality
  • What the customer needs
  • Delivered on a timely basis

Doing a customer satisfaction survey to get a baseline, then again measuring quarterly how are we doing? And sharing it with the team is important. Focus groups with the business customer that include all the team is also useful.

And of Course – Budget for and Measure Against a Plan

DO NOT LOSE SIGHT OF DOCUMENTING PROGRESS AGAINST A BUDGET AND A PLAN. These are expensive programs. They are also not easy to accomplish. So like all good agile work, create a vision and translate that into a rolling quarter roadmap. Break the roadmap down into adoptable features and lay them out in the roadmap. Develop a release plan per quarter just prior to that quarter and execute against that plan. Some key components of this:

        • Make sure you have a plan
        • Make sure you document results against the progress (or lack of) against the plan
        • Be prepared to chuck and re-write the plan

The same applies to budgets – by making work visible and measuring your accomplishments against them, it will be a lot easier to get budgets approved so you can move forward with the work.

FYI a great Project Management technique I found when things go wrong (notice I said WHEN not if) Be the first to note you screwed something up, then quickly move forward to figuring out how to fix it. It takes the focus off the finger pointing and the blame game and moves you into define the problem domain in an us against the problem mode.

I hope this has been informative. Stay tuned for the next article in our series that will address the potential landmines and pitfalls to watch out when implementing a large scale agile transformation.