Agile Forest

Find your path to agility with Renee Troughton

The world of Agile training and mentoring is intriguing me at the moment.  This is how most of us have done it in large organisations for a long while –

  • We build in powerpoint or prezi these gorgeous training decks and train up people new to Agile
  • We outsource our training to groups who do the same as the above
  • We build intranets, wikis or documents worth of content on “how to do <insert Agile activity here>”
  • We teach the “Shu” rulebook without constantly re-enforcing the need to progress to “Ha”
  • We have embed games to re-enforce and experience learnings from training sessions
  • We mentor through SODOTO (See One, Do One, Teach One), but often never get to the TO bit

We talk a lot about innovation and radicalizing the business and yet some of the training techniques we still use are from 1990s. How many Scrum Masters open up this content and use it? How many Scrum Masters experiment and adapt how they work? How transparent, engaging and interactive is this content? Playing games and implementing SODOTO is a great start to interactivity and real-time knowledge sharing, but can we do more?

Recently I have had an awesome opportunity at Charter Hall innovate, experiment and enhance the experience of learning differently. Rather than build decks I have spent many hours building an interactive wall to people new to Agile. It is more an experience than a training session. It is one massive wall that flows a conversation about Agile quite naturally before the tour moves further into the working space.

The “basics” tour has the following elements:

  1. The background of Agile
  2. The Agile Values
  3. The Agile Principles
  4. The Agile Process
  5. The Agile Roles
  6. The Portfolio Wall
  7. The Pipeline Activities Wall
  8. One of the Project Walls

The principles behind the learning wall are quite simple:

  • Create a natural flowing experience
  • Introduce concepts with visual drawings to enable better retention
  • Make the process introduction really simple, bare bones, but…
  • Have the ability to drill through into detail without it overloading the audience. This would help when having more detailed role training.
  • Make everything transparent, no content is hidden in a tool
  • Break up content so that as things change it is a simple matter of changing one small picture

Now before I show you the pictures of what I have created I do want to highlight some intended future changes:

  • Extend the values section to include the Scrum values and the company values
  • Make pictures for the Agile Principles
  • Add in Lean Principles
  • Add in an “other section at the tail end”
  • Maybe add in a visual around all the different Agile methods, edgy and support methods
  • In addition to the wall I am also building a series of agenda cards – these are re-usable packs for Scrum Masters and coaches to use for workshops and key Agile activities (eg Iteration Planning, Retrospective, etc). These cards have some spares so that facilitators can adapt away from the standard set of agenda ideas. On the back of the cards are tips of the purpose of agenda activity and how it could be facilitated.
    What does this mean for a new facilitator? Well they have the clear activities they need to do with how to do it without having to open up a tool (which they don’t ever do), but most importantly this is real time – exactly when they need it. It also provides great clarity to everyone else in the room around what is happening and what still needs to happen when it is utilised as a backlog against a simple wall of “To Do”, “Doing” and “Done”.

Anyway, now for the pictures of the Learning Wall (it runs right to left due to the entrance point, but normally I would have preferred a left to right run). Taken from the right:

_DSC2108

 

Taken from the left:

_DSC2098

The Agile Values (some references taken from Rally’s awesome values picture):

_DSC2071

The Agile Principles:

_DSC2074

The Agile Process (note this is naturally a very specific organisational tailoring, I am by no means saying this is the one and only process for Agile). Specifically, this is the bare bones view. The number of iterations is just for an example.

_DSC2079

And now the interactive version (note how the interaction points line up with the number of iterations).

_DSC2076

With a detailed closeup on the iteration portion:

_DSC2077

A high level overview of the Agile Roles. The three key Scrum Roles are here – Scrum Master, Product Owner and the Team. In addition I have added in our organisational specific governance roles which includes a high level organisational wide steering group, a Business Scrum and the PMO. Again I would like to highlight that some changes have been made to normal roles to suit the specific culture and needs of the organisation.

_DSC2081

Detail on the Scrum Master role (interactive side showing):

_DSC2093

Detailed view on the Product Owner role (bare bones side):

_DSC2089

Detailed view on the Product Owner role (interactive side):

_DSC2094

Detailed view on the Team role (bare bones side):

_DSC2087

The Business Scrum role:

_DSC2086

The Steering Group role:

_DSC2090

The PMO role:

_DSC2085

And that is the Agile Learning Wall! Please feel free to comment on any thoughts and suggestions to enhance the route of complete transparency and no tools that I am on.

I would like to thank both Nicki Doble and James Doust from Charter Hall who gave their support for my experimentation and for their willingness to expose to the world what we are doing.

 

Over the years the roles associated with agile transformations has grown and changed. Fifteen years ago the only roles that existed were those that were associated with being within an Agile team – the Product Owner and Scrum Master. agilecoach

The Scrum Master role hasn’t really changed over this time – it has always been clearly in their remit that they are responsible for training, mentoring and coaching the team in Agile and for ensuring the Scrum process is understood and enacted. So how is it that about five years ago the role called ‘Agile Coach’ came about, and more importantly, what does it mean?

In Australia, partly the distinction was made initially not because it meant something different to a Scrum Master, but because a lot of organisations and transformationalists didn’t want to tie themselves solely to Scrum. This meant that a more general sounding name was needed and Agile Coach came about from that. Over time though, in my personal opinion, it has indeed changed to have some differentiation from the Scrum Master role.

The predominant difference I see between the Scrum Master role and the Agile Coach is not the responsibilities but the experience. Because anyone can do a two day CSM and call themselves a ‘Scrum Master’ there has been a gap of a lot of people who know only the very basics and those that know in reality, through practical application and experience what works and what does not. An alternative to look at it is the broad spectrum of Scrum Masters who are in Shu trying to mentor and coach a team without the skills to be able to do it, versus those that are in the tail of Ha, or even starting to hit Ri. What ‘Agile Coach’ gave us was a means to be able to differentiate between someone who had done a two day course and someone who had lived and breathed transforming teams for a few years.

If I was to put some clear differences into bullet points it would look something like this:

Scrum Master

  • Done a 2 day CSM/PSM course
  • Applied Agile to a single team, once or up to a few times
  • Reading the basic Agile books
  • Basic knowledge of values, principles, process, practices and techniques of Scrum, XP and Kanban

Agile Coach

  • Done potentially more certifications (or been mentoring, coaching and training teams for more than five years)
  • Been mentoring, coaching and training teams for more than three years
  • Starting to read most of the key Agile and Lean books
  • Applying knowledge from a variety of methods including scaling methods, lean and systems thinking
  • Uplifting capability of multiple teams through working closely with several Scrum Masters at once
  • Training, coaching, mentoring and advising not just teams but also leaders
  • Tries to resolve complex departmental waste issues

In addition to the two roles above, another one seems to have entered the agile vernacular in the last two years – that of an Enterprise Agile Coach. So lets take a look at my personal opinion of differentiates an Enterprise Coach:

Enterprise Agile Coach

  • Has led an agile transformation or whole divisions at one or more organisations
  • Has had a team of Agile Coaches working with them to undertake the transformation
  • Defines the organisation’s Agile framework and ensures that buy-in exists at all levels to the change
  • Has read most of the key Agile and Lean books, has started reading practices and techniques that are outside the Agile community including modern management, complexity, finance, metrics, behavioural and organisational change.
  • Training, coaching, mentoring and advises not just teams and leaders but high level executive and c-suite managers
  • Tries to resolve complex organisational waste issues including governance, finance and HR.

So in conclusion, for those of you that were confused about the difference in the roles, I hope this helps. If I have missed anything or you feel that according to your views I have mis-representated something than feel free to comment below. The responsibilities and experience levels noted above are purely my opinion and based on what I have seen and experienced around me in Australia and New Zealand.

In product development the definition of Minimal Viable Product (MVP) is

The product with the highest return on investment versus risk

Popularised by Eric Ries it subtly changes to

The smallest thing you can build that lets you quickly make it around the build/measure/learn loop

I must profess I have a few issues the MVP concept.

mad-scientistMy first is the term. The term MVP is all well and good for you version 1.0 of your product, but what exactly is your next cycle through the loop called – is it called a Minimal Viable Product as well? Why do we not refer to the refinement or further iterations of the build, measure, learn (BML) loop as Minimal Viable Increments? Or better yet, BML increments? We know from using Lean Startup that we rarely get the product right first go, so we should have some simple term that talks about getting it closer to right shouldn’t we?

My second issue with MVP as a concept is that people forget that there is a life cycle to products if you do manage to be successful post the Startup phase. Let’s go through the scenario – you build your first MVP, you increment on it through build, measure learn, you begin to realise customer value, customer growth and manage to retain customers, you increase business revenue; in essence, your startup starts to succeed. Then your customers continue to grow. Suddenly your little tiny product is not handling the growth. You need to desperately take what was a tactical solution and industrialise it, strengthen it so that it can handle the next stage of growth. Your minimal tactical product just isn’t cutting it, it simply isn’t viable anymore. At this point in time the increments from a BML perspective need to focus on operational sustainability – how can you build a platform to sustain an acceptable performance? I call these minimal strengthening increments.

My third issue with MVP is that if you are doing it in a non startup environment – ie an intrapreneur in an already existing and flourishing business, is how to deal with reputational risk. In these large corporate organisations you need to worry about compliance to major standards, either in the country or internationally, you may also need to worry about how your existing shareholders feel about a non polished product out in the marketplace. It is for this reason that you could venture down the path of white-labeling the product, ie taking your brand off it and registering it under a smaller shell of the company, but often it means that the MVP becomes not so very minimal as the company is unwilling to incur reputational risk.

My fourth and final issue with MVP is the very difficult balance between MVP and minimal viable experience (MVE). Sure you could put a product out there to begin learning from, but if the content or the experience of the product is not compelling enough then you are going to risk turning away customers and that comes back to reputational risk for large corporations. Some call this a minimal lovable product.

Don’t get me wrong, I love Lean Startup, but in conclusion, if you are applying it into a corporate environment it is not going to be enough to ensure success and many different considerations need to me made. In a large and established organisation consider the minimal viable increment, the minimal viable experience, the minimal riskable product, and the minimal strengthening increments.

Inventory waste. It is one of the eight forms of Lean waste. It is work in progress or finished goods which are not having value added to them.

In software development inventory waste is best represented in the queued activities in between the hand offs from individual to individual. If using a complicated board, you would represent the full flow or value stream for delivering stories. This would normally contain columns such as “Ready for Development” or “Ready for Testing”. A build up of one or two items in these columns isn’t necessarily bad, but when moderate to large queues start to appear it is symptomatic of constraint or flow issue within the team.

In teams doing Kanban well, they are limiting their work in progress across both the active and the queueing columns (ie “In X” and “Ready for Y” columns).

What a Hotspot board does is visually highlight the inventory waste areas of the team’s flow. Rather than structuring flow going across via the headers or columns, it balances the zones of the board so that the inventory waste areas are all in the center part of the board – ie the key focal area of your eye, highlighting the criticality of watching these waste points by backing the zone in red.

HSB1HSB2

There are a few potential downsides to such a board:

1) Swimlanes become difficult to utilise as a visual technique (as flow bounces around the board)

2) Visual fixation on only the hotspot results in the “In X” activities having reduced focus. This could result in high WIP of in flight work being ignored which would definitely not be a good thing.

To overcome this second issue and to align more closely with one of Kanban’s key pricinples, limit work in progress, I extended the idea of the Hotspot board to become the Twister board (yes like the game with spots).

The Twister board re-introduces work in progress limits in three ways – HSB3

  1. In the hotspot zone itself
  2. In the active flow states – visually highlighting the actual kanban availability through the existence of the circles
  3. In the active flow states – visually highlighting the risk of hitting to top threshold of work in progress through colour – green =  all good, orange = getting close, red = upper threshold of work in progress being met

Note: pictures are examples only of flow and work in progress limits. As always, apply this contextually to your work and teams.

The 1670 saying by John Ray’s A collection of English proverbs

The early bird catcheth the worm

is well understood by many. The phrase conjures up a picture of birds sleeping and waiting whilst the one that leaves it’s nest early to scourge for food will be more likely to succeed in having a full stomach. catch-the-worm-early-bird

But take a step back and think it through a little. Is there a higher likelihood of worms the earlier a bird rises? What are the other birds doing? Does getting up earlier mean a longer duration of scouting ability unimpeded by competition?

Worms don’t have eyes and hence do not detect the rise and fall of the day. In this respect the worms are always there, it is merely the availability of sunlight that enables the worm to be detected. Where I live there seems to be an abundance of worms after rainfall, otherwise it is slim pickings.

I think the essence of the proverb is really about competition and that engaging an activity with reduced competition has a higher likelihood of success.

It made me think about the submissions process on a number of conferences like Agile Australia. A few weeks ago I got together with the other stream reviewers that we have in The Basics stream. We spent time pouring over the submissions made to date, trying to get to a similar set of assessment conditions and talking about the feedback that we would give. We have a great opportunity in this stream to give awesome feedback as for the very first time all reviewers are in the same city so we can physically meetup on a regular basis and communicate in a very Agile way.

The number of submissions to date in both this stream, and even the conference overall, have been trickling in. I know what happens after seeing it year after year – most of the submissions come in the last week. Whether this is because people are waiting to see if they can submit on a niche topic or because everyone used to be the sort of people in high school that would do their assignments at the eleventh hour (yes I was one of those people too), it discombobulates me that we do this in the Agile community.

It discombobulates me in two ways –

  1. Agile is based upon early delivery and fast feedback cycles. If any community in the world should cherish being the early bird and getting rapid feedback it should be us – and yet most submissions come in the last two days.
  2. We, as reviewers can give much more considered and thoughtful feedback the earlier we see the submission. The more feedback you get…. guess what – the more opportunities you have to course correct the submission. The more opportunities you have to course correct the submission – the more likely you are going to be hitting the target of what the reviewers are looking for. The more likely you are going to be hitting the target of what the reviewers are looking for – the greater the opportunity to make it into the short list to present.

And so, I plead with you – if you are keen to present in Agile Australia, please submit now and not in the last week!

TeamTypes

Scrum as implemented within teams is something that many of us have been doing for a while. It isn’t a simple implementation, but we have done it for over a decade. As teams begin to invest in applying Scrum at scale, the complicated quickly becomes complex. Methods such as LeSS, Enterprise Scrum, SAFe, DAD and Spotify are good examples of where people have aimed to return this complex set of activities back to complicated.

But they are all missing the realisation of a very simple concept, that all people and teams are not created equal. Sure there is a vast appreciation in these methods of the concept of teams – teams that are autonomous, fully empowered to work with their Product Owner to deliver customer value. These teams, often known as feature teams, pull items of larger work off a portfolio backlog, a backlog recognised to often be owned by someone further up the organisational chain of decision making.

However, where are the technical leaders in this? Where are the managers, be it project managers, or people leaders? Some would argue that in a truly agile organisation such roles shouldn’t exist, and maybe a more lean or autonomous organisation would seek ways to immediately remove these roles. But in a transformation, when so much is in flux, when there are already so many risks of change around, maybe there is another way.

What could the alternative be? What if we could be more tolerant and respect people’s roles and the value that they could provide in these roles?

This blog post is dedicated to such an approach and seeks to discover and highlight the concept of team types.

 

Feature Delivery Teams

The first team type is the one that we all know best. This is the team that does Kanban or Scrum, or whatever else in order to deliver value to customers. This type of team commonly works off a Product Owned backlog.

Interestingly, at scale they can be either one of many teams delivering as part of a product centric focussed tribe or part of a project centric focussed tribe. Which approach of tribal grouping – project versus product would depend on multiple factors.

This team should also be accountable for the outcomes that they deliver to production – work is not considered complete until the benefits have been realised through hypothesis validation, and any production incidents are also owned and resolved by this team. In simple terms, rather than passing off their problem to another group who only do fail and fix, this team “fixes whatever problems it may create”. In this respect, the team will have a clear desire on good quality software and reducing technical debt because they will also own the maintainability of the code. If technical debt or refactoring is ignored by the Product Owner, they will acutely feel the pain of it further down the line and consequently better appreciate the balance of feature delivery with quality.

There are three points that need to be highlighted for feature delivery teams:

  • The backlog, owned by a single person, the Product Owner
  • This backlog will contain Features and User Stories for the team to work on. This work is expected to provide an outcome that results in either increased customer value, increased customer growth, increased customer retention, increased business revenue or increased cost avoidance. In high feature outcome focussed teams, increased business revenue or increased cost avoidance, are usually related to customer centric features. In a more balanced team, for example one with a stronger devops focus, some features are less direct functional and are more focussed on increased customer retention through reliability and availability of performance. But this balance, or sliding of focus is probably worthy of a separate blogpost.
  • The team’s regular cadence around their transparency of work, often known as a Daily Scrum, Daily Standup or a Huddle, is focussed on the individual work items, blockers to progress and potentially the current team goal.

Project Support Team

Not necessarily applicable in all organisations, if the Agile transformation hasn’t tackled removal of the term “Project”, or if it simply makes more sense to bundle together like business goals that cross cut multiple products, then the project support team is an important team to recognise for the value that it provides.

Common activities that this team will own include:

  • Managing (solving and potentially further escalating) risks and roadblocks escalated up from the feature delivery teams associated with the project
  • Raising risks and issues to the Product Support team if they are more globally impacting than the project itself
  • Managing the project financials
  • Maintaining user experience consistency across all of the feature teams associated with the project
  • Managing cross team dependencies
  • Maintain the Project Delivery Roadmap and definition of the Minimal Viable Project

There are three points that need to be highlighted for the Project Support Team:

  • The backlog, is owned by a Chief Product Owner, with Feature Delivery Teams executing on the items in the Portfolio backlog through their work with their Product Owner. Arguably the activity of portfolio backlog management could be considered a Project Support Team responsibility, but clear accountability lies with the Chief Product Owner.
  • This portfolio backlog will contain significantly large enough activities for a Feature Delivery Team to break down and work on. These could be loosely called “Features” or may be even bigger and called “Initiatives” and “User Stories”. Most of the Project Support Team’s work however is risk and issue management and such doesn’t exist as a backlog but should equally be managed in a transparent manner.
  • The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues.

Product Support Team

In the duel relationship with the Project Support Team, the Product Support Team is an important group of people who own the multi-team related risks, issues and release activities related to the Product (sometimes considered a platform or channel).

Common activities that this team will own include:

  • Managing (solving and potentially further escalating) holistic risk to the product based on release drivers from the feature delivery teams
  • Aligning marketing campaigns to potentially drive down multiple messages being released at the same time for the same product
  • Working with other areas of the organisation to prepare them for release readiness
  • Demonstrating to all teams working on the Product the recent changes- think of this as a multi team Sprint Demonstration so that if teams are working on different projects they have the opportunity to be aligned with how the product is changing
  • UX consistency, patterns, standards and alignment where multiple feature delivery teams are impacting the same product zones
  • Architectural vision and guidance (note execution should be with the feature delivery teams)
  • Performance and penetration testing
  • Capability uplift of teams with respect to critical changes to either the product or process to deliver on the product

In a number of cases, the greater the amount of automation that this team or the feature delivery teams can build in to reduce the above activities, the better – especially when it comes to release and testing automation. Note that I haven’t even mentioned production acceptance regression testing as I do fully expect the feature delivery teams to build up this suite.

In SAFe, this is where the Release Train Engineer and the Architecture related elements may fit in, but I don’t really see this team as delivering architectural features, they are responsible for product delivery capability.

There are three points that need to be highlighted for the Product Support Team:

  • The backlog, unlike the Project Support Team, is likely a multi Product Owner scenario, with the full Product Support Team driving and agreeing to priority.
  • This backlog will contain activities for the team to work on. These could be loosely called “Features” and “User Stories”, but the customer in most of this work is not going to be an end user and is more likely to be an internal customer such as the Project Support Teams, the Feature Delivery Team, Marketing, IT Service Centre, Risk or Compliance areas of the organisation. This work is expected to provide an outcome that results in either increased customer retention (through minimised interruptions/updates), or increased cost avoidance (through risk avoidance).
  • The team’s regular cadence, more commonly known as a Scrum of Scrums, is focussed on mitigating risks and issues, transparency and execution of both release management and of capability uplift activities.

Conclusion

I understand that many people will read this blog and go “that’s not very Agile”, but the reality is that a transformation doesn’t happen overnight and unless you have a horde of Agile Coaches going across massive 30,000 people, you are going to have to pick and choose battles, with those battles often not immediately targeting both governance, finance and human resources sections of the organisation.

This is a way of an intermediary step until you may be ready to transform systemic organisationally wide dysfunctions.

In oldschoola query that recently spammed the Agile universe by Abder-Rahman Ali was a question posed about the difference between User Stories and Software Requirements Specifications, specifically

1) Do you think that “user story” is just a fancy name for SRS?

2) How do you compare a “user story” to “SRS”?

3) Do you think that “user stories” replace “SRS”?

4) Which of the two do you prefer working with?

So let me open with a clear positioning stance:

User Stories are not a fancy name for an SRS, they are not the same thing, they should replace an SRS when working in an Agile environment and I prefer working with User Stories.

The following comments are focused on how I believe they are different and are naturally based on subjective opinion.

Origination

A SRS is usually created part way through a project, once the Business Requirement Specification (BRS) has been crafted and signed off. An SRS is crafted by a Business Analyst, often with minimal collaboration to other team members and the business throughout its development. As part of its development the BRS is cross referenced to ensure traceability. Once produced the SRS undergoes a review and approval process that does generally have an extensive audience. Often this review and approval process can take several versions until the document is deemed correct.

A User Story can be created at the start of the project or throughout the life of the project. Through a collaborative workshop(s) called “Inception”, features are defined. Often these features are broken down into User Stories using the Story Mapping technique. As everyone who needs to deliver the project is in the room there is no handoff of documents and no extended review and approval process.

The key differences in the origination process is that User Stories are not dependent on the existence of a BRS to be created, that everyone is engaged to identify and define the requirements, and that there is no formalized approval process (because it is not needed if we are one team, all responsible for the outcomes that we agree to).

A simple analogy is that Inception is requirements gathering on steroids.

Content

SRS content is often lengthy, comprehensive but lacking depth to implement against. Normally, an additional deliverable is produced in between the SRS being delivered and software starting coding (normally referred to as a Detailed Design Document, or DDD for short). Field rules, expectations of behaviour under error or abnormal conditions are also specified within (sometimes as an appendix, or separated out into an additional deliverable). There are often multiple SRSs to a single BRS, but rarely would this number exceed a magnitude of 10. How a SRS is tested comes down to separate test deliverables.

A User Story is a promise for a conversation. It is often a single sentence written as a narrative of “As a <persona>, I want <requirement not solution>, so that <value obtained>”. In addition to this single sentence the conditions under which the User Story will be tested are included as Acceptance Criteria. Well-formed User Stories, like system requirements, cross cut components or architectural tiers of the system(s).

Critically there is an expectation that the documentation of the User Story itself is unlikely to be sufficient or comprehensive. The conversation placeholder is the opportunity to discover these elements of the requirements and to clarify needs in person with a business representative. This conversation has representatives from all specialists. This conversation may also extend to a group of developers in order to determine the best architecture or design to deliver the User Story. In this respect a DDD is not normally produced, but photos of whiteboard outcomes are kept in a repository for prosperity. Field rules are often discussed as part of this conversation.

Expectations of behaviour or abnormal conditions are often split out from the story – ie a new User Story is created per condition or behaviour to handle expectations. In this respect a single business need, described within Inception as a Feature, may result in potentially several dozen User Stories. This is especially true when good User Story splitting principles begins to focus on one Acceptance Test per User Story and the team moves towards an estimationless environment of reduced User Story size variability.

Change

As part of the SRS development, as the BRS may undergo several change requests. As part of the DDD development, test deliverable development, actual development & testing the SRS may also undergo several change requests. Over the life of a Project this could result in hundreds of change requests to approved deliverables – this is to ensure that what is delivered is of value to the end user, otherwise the system is unlikely to meet their needs. Each one of these change requests takes the team away from delivering to estimate the impact of the change.

As User Stories never undergo an approval process they can be changed at anytime prior to a developer picking it up to deliver. The cost of change at this point in time is negligible with conversations often being the only highlight. Once development has begun there an team internal change policy often guides what happens next. As a rule of thumb, if the change would take the team less than 30 minutes to do then it should be absorbed, otherwise the change should be raised as a new User Story. That User Story then gets prioritised by the Product Owner and may or may not be done based upon that priority. As a rule of thumb, unless the original User Story was completely off base, then it would still be delivered as it stands, otherwise it would be pulled from development.

Realising value

A SRS does not have it’s value ever realised or assessed. The BRS is tied to benefits and it consequently gets assessed for benefits realisation. Only through traceability of requirements is there confidence that the SRS realises value. From a delivery standpoint, only once all the SRS(s) and BRS has been delivered does the software often go into production. The outcome, is often a delivery near the realm of a year or more. The benefits realisation activity is consequently months, if not years after the production delivery.

Both the Features and the User Stories realise value within their originating narrative of “so that…”. As developers deliver User Stories they can go into production once they have been tested against their acceptance criteria. For iteration based team this often means fortnightly deployments to production and consequently a fortnightly realisation of value. Sometimes teams may not release to production at the end of these iterations because a minimal viable product is still not achieved. Some teams, especially those that have focussed on technical excellence through continuous integration and continous delivery, can realise value several times a day through regular deployments to production.

When Agile teams take on Lean Startup practices a User Story does not get deemed completed or done until analytics have been gathered in production to prove or disprove the value realisation.

A good analogy of Lean Startup as it applies to User Stories is “continuous micro benefits realisation”. In this respect, Agile teams have a higher confidence that they are reducing the #1 waste in software development – building the wrong thing, because they are constantly checking with real customers if they are on the right path (not the proxy customer who may be the Product Owner or Business Stakeholder). The other key difference when Lean Startup applies to User Stories is that the narrative alters to no longer be a requirement and instead is a hypothesis that critically should be proven.

Estimation

When a BRS is completed the service delivery team does a detailed estimate to deliver not only the SRS, but all artefacts and actual software delivery outcomes. The change request process is often the only means to recover further money. Critically, this estimate is done when the largest amount of unknowns are still unknown. Re-estimation after the SRS is completed is not normally done, especially in fixed price bidding environments. Estimates are commonly done by Project Managers and Architects and have next to no input from the people who actually do the work. There is no relationship to SRS and actual delivery rates (with the exception of the rare teams that still do Function Point Counting).

In Agile teams estimation is done throughout. Both Features and User Stories are often estimated, but critically not in hours or days. Instead Agile teams used comparative based estimation techniques where one User Story’s complexity is compared to other already existing estimated User Stories to best gauge its approximate size. As teams begin to deliver User Stories they track throughput rates, either by cycle time or amount of work done within an Iteration. This information is then used to forward project confidence of delivery. All team members are actively engaged and encourage to estimate the User Stories as a single unit.

Conclusion

It is hard for me to write all the above content and not continue to think “Why do we still do waterfall?” especially in the commercially fast paced world that we live in these days. An SRS is not the same thing as a User Story. The outcomes that each achieves are quite different because of how they are utilised, not because of the description of the need that is within them.

Korea

North Korean Innovation

 

A North Korean Architect was commissioned to draw a futuristic version of North Korea with zero limits on both financial feasibility or even

structural integrity.

The result? In what seems straight out of a 1963 ‘The Jetsons’ episode, the architect seemed to produce drawing after drawing stuck in an era of decades past. Simplistic treehouses, ancient decor and ordinary footbridges made up a few of the images created.

So why with such an open remit did the architect produce such backward thinking results? Maybe it was purely the individual, maybe they misunderstood the brief, or maybe this is a glimmer of what happens when innovation is stymied by a lack of injected ideas.

1963 Jetsons apartment

1963 Jetsons apartment

The secret to innovation isn’t just having the time to think freely, but also having a great depth of material to draw on. This architect was not influenced by decades of shifts and ideas in architecture.

So the next time you think that innovation is all about having 20% downtime or having hackathons, think about the learning culture you are creating instead. Are you creating a learning culture to enable innovation or are you just enabling the creation of more Jetsons apartments?

magicThere are some great things about Scrum. Having a regular cadence for planning how to do work, working together to progress work and regularly reflecting and getting feedback both on how we work together and what was delivered are all great concepts.

But I have come to a somewhat scary hypothesis that it isn’t the practices, the roles and the artifacts that are actually making Scrum successful.

I think it is because you are taking your inefficient, over bloated process and replacing it with a very simple method. It works because you are taking something very heavyweight and replacing it with something lightweight.

You see, the trick to succeeding at Scrum, isn’t really the implementation of Scrum. It is whether you win the culture over process race.

As you get more used to Scrum you find weaknesses, areas where it isn’t dealing with organisational problems and you start to add in process to fill the gaps. Usually what you add in is something similar to what you used to do. At the same time, you are trying to transform the culture by changing hearts and minds towards Agile – to be agile rather than just doing Agile. This is the culture shift. When you have succeeded in this culture shift you would be less likely to introduce the additional process.  Basically you have to be faster at changing the culture to enable pushing back on process bloat over the injection of new process.

This is arguably why SAFe could be a little less effective in transformation and in significant improvements – because to an extent the process is probably more medium-weight and doesn’t do enough to push back on process waste.

So the next time you plan on changing a way a team or organisation works, think about why it may be working and focus on whether every additional step being added in after the change will really add value. I find that 80% of process is added in to handle less than 5% failure scenarios. There has to be a better way.

agiledoesntworkOn my way to someone’s desk at work I overhead a blunt and emotive statement “Agile doesn’t work”. I smiled slightly and hung back to overhear the conversation further.

I learnt through listening that the person making the statement was a Product Owner. They were unhappy with the fact that their team hadn’t been delivering on their product backlog, that they team instead had gone off and begun to work on something else.

I was a little shocked to hear this, and could deeply empathise with the concern. If it was the case then the team was indeed not performing to expectations.

I spoke to the Scrum Master later about it (note they were not a team that I had direct coaching involvement with) and learned that team had actually begun working on something else because it had been a directive that had come down from several layers above the Product Owner.

Delving further, the reason why the Product Owner only knew about this after the end of the Sprint was because:

  1. They were not investing their time co-locating with the team
  2. They were not attending the Daily Scrum nor Sprint Planning

… and people wonder why Agile gets a bad rap.

So the real issue here was never that Agile didn’t work, it was that:

  1. The Product Owner wasn’t investing properly in their role, either because they were overstretched (poor capacity planning), or due to care factor (bad engagement)
  2. The Product Owner wasn’t co-locating, again either to being overstretched or due to physical desk limitation issues
  3. The Product Owner was superseded by his own management and yet his management failed to inform him of this change in direction

Some would also say that the fact that the Product Owner’s management trumped his work is an indication of concern, that he may not be empowered to calls the shots. Normally I would suspect such a problem, but in this instance this was an urgent unplanned change that impacted hundreds of people and dozens of teams, it was highly irregular.

I asked the Scrum Master if they would be willing to talk further through the above problems with the Product Owner in order to reach a common understanding of where the problems with Agile in the team were.

Conclusion

Agile does work. It, just like any process, needs people to understand the process and follow the steps to enable it to succeed.

Follow

Get every new post delivered to your Inbox.

Join 1,152 other followers