Tag Archives: Lean Systems Thinking

Business Agility for Beginners

Leave a reply
Rufous Hummingbird_Alan Schmierer_640x516

Flickr Commons, Rufous Hummingbird – Alan Schmierer

There’s a new crop of thinkers who are noticing that while Agile and Lean Startup approaches are being enthusiastically embraced by organisations, they are mostly being implemented at a team level. The promised improvements, such as quicker delivery of product and happier teams may well be there, but the organisational improvements that will lead to innovation and customer value are not fully realised.

Barry O’Reilly summarises this perfectly when he explains how difficult it is for organisations to implement Agile and Lean Startup across the enterprise. He explains, “In most cases it [is] impossible to realize anything more than incremental improvements because only part of the organization [has] changed – and that part need[s] to work with the rest of the organization, which expect[s] them to behave in the traditional way.”

Jez Humble, Joanne Molesky and Barry O’Reilly’s fabulous book, Lean Enterprise: How High Performance Organisations Innovate at Scale, describes how successful organisations rethink everything, from financial management and governance, to risk and compliance, to systems architecture, to program, portfolio and requirements management, in the pursuit of radically improved performance.

Business Agility is about developing the patterns across an entire organisation to fulfil on the promise of Agile and Lean Startup:

  • Minimum viable everything – product, experience and process
  • Measure outcomes (value), not outputs (stuff done)
  • Experiment to learn – create a generative safe to try culture to continuously improve

Through meeting with thinkers at the forefront of Business Agility; Barry O’Reilly and Pat Reed, I’ve collated these questions to help organisations grow Business Agility.

Minimum Viable Everything

Do our processes generate value, rather than hold us back?

Can we map how much time we spend on value generation versus being busy?

Do we create “won’t do” lists to focus on the most valuable activities we should be doing?

Measure Outcomes no Outputs

Do we measure value in terms of making an impactful difference to a customer or to the business, with the least amount of output – more value at less cost?

Do we make value visible throughout our product development cycle?

Do we have a value model that provides a clear line of sight for everyone in the organisation on the work they do and the outcome desired?

Do our leaders articulate what success looks like in measurable terms and with real clarity, so the whole organisation can align on delivering value?

Do our metrics and reward systems measure outcomes (value) not output (more stuff done)?

Do our metrics measure the cost of value and time to value?

Do we balance business value and customer value for a sustainable organisation?

Experiment to learn

Are we an organisation that can thrive in extreme change?

Do we have feedback loops to ensure we understand:

  1. How we’re doing based on our commitments?
  2. How quickly we are learning and responding to customer feedback?
  3. If we are still doing the right thing, or if we need to change our goals based on shifting circumstances and priorities?

Do we accept that there are many unknowns, and recognise that everything is an experiment to discover where value actually lies?

Do we define tests as part of the experiment? Whether it’s a feature in a product, or a change to a process, do we identify the value which should be improved by the work, and then measure if it has been achieved?

Do we have a tolerance for failure, by testing first with a hypothesis, and being open to learning when the hypothesis proves not to be true?

Do we adapt quickly and celebrate learning?

Do we generate knowledge across the organisation by sharing the results of experiments, especially the failures?

Do we avoid big failures by breaking big challenges into thin slice experiments?

Do we accelerate feedback loops by shrinking the learning cycle to days or weeks and iterate?

Organisations on their way to Business Agility will recognise the above questions as aspirational. They will also recognise that opportunities to improve are everywhere, or as Barry O’Reilly expresses, “not just in the products or services we build, but in the way we behave and interact and most importantly, in the way we think”.

Who is the new Agile leader?

Leave a reply
Into the Unknown - Thomas Hawk - Flickr Commons

Into the Unknown, Thomas Hawk, Flikr Commons

My previous blog put a case for why we need a new style of Agile leadership. To enable self-managing teams to contribute and thrive within the complex ecosystem that is the organisation of today, Agile leaders need to understand their role as fourfold:

  1. As a coach; to share knowledge, skills and perspectives to development people
  2. As business driver; to maximise product lifecycle profits
  3. As purveyor of purpose; to connect people with the purpose of what they do
  4. As an enabler; to support  people to thrive within their environment

Even for traditional managers, there’s probably nothing controversial about these four roles, inspired loosely by the thinking of Michael Hamman and Michael Spayd. In fact to varying degrees, traditional managers might even feel that they fulfil these four roles now.

Traditional managers may perceive themselves as coach, in that they expect individuals to develop a learning plan, and if time and budget permit, they support an employee achieving it.

Nigel Dalton, CIO of REA Group, described in an ITNews interview online as, the Godfather of Agile in Australia, describes the role of Agile leader as coach:

“The company is divided into a set of teams focused on a kind of consumer ecosystem where each one is discreet from the others. Commercial property owners is mine; which is the smallest one. [The others are residential property owners and property developers]. We have understood that [there] is a kind of …‘unique customer experience’ in each one of these ecosystems.

[We asked] what if we put a full multidisciplinary team on those, and we chose a collective group to manage it?

Thus, I am not the general manager of commercial real estate – there isn’t one. I am the steward or coach of a group of seven people who are IT, sales, marketing, product, legal, finance, and human resources. Young managers in their thirties, who’ve got every competency to work as a team, and run that 40 million dollar business. I am there as their coach and all the Agile techniques come in under that. It is pretty self-contained and self-directed. It has its purpose and goal that flow down from the main company purpose. We have replicated that across the company – this is the primary structure.”

In traditional management the focus will largely be on the business role. The narrative on this would be “I reward individuals and teams who do whatever it takes to get over the line”.

The purpose role is a tricky one. Barely a middle to large sized enterprise today exists without some sort of mission statement. In traditional management, the existence of this mission statement and some resultant values might be perceived as bringing purpose to people working in an organisation. I can tell you from experience though, that the yearly exercise of requesting folks shoehorn their performance into the predetermined values of the company doesn’t yield much sense of purpose.

And finally to the enablement role. Traditional managers no doubt perceive themselves as enablers. They want their teams to succeed and would do pretty much everything to ensure this happens. I question though whether traditional managers would always take a holistic approach to enabling, seeing their team’s role in success of the whole organisation, rather than just success of the individual team.

Lisa Frazier, in her talk on Agile leadership at Agile Australia 2016, described how an Agile leader enables, by adopting a “follower-centred leadership style”. She cites three behaviours associated with this:

  1. Working for success of your team members above yourself
  2. Actively listening to your team
  3. Being a good follower

My favourite quote ever is from Nigel Dalton, at the same conference: “Leadership is not boss-ship, it’s servant leadership. Don’t ever mistake not being at the front with not being the leader”.

Jeff Smith, CIO of IBM, in the keynote address at Agile Australia 2016, said that “people come to work because they are ambitious and share the mission. The leaders’ job is to remove the obstacles”. Throughout this series of blogs, I’ll explore how great Agile leaders fulfil on their role as enabler.

Throughout this series of posts, I’ll contrast the role of Traditional Managers with Agile Leaders. What happens, when we ask great Agile leaders to reflect on these four roles in relation to the following leadership activities?

  • Decision making & problem solving
  • Communication
  • Delivery
  • Learning
  • Acknowledging success & rewarding right behaviour
  • Continuous improvement
  • Innovation

Read on to discover the questions great Agile leaders ask themselves in realtion to these activities.

 

Why Agile leaders need to ask themselves new questions

Leave a reply

steampunk

We know that organisational culture can be shaped by the worst behaviours leaders are willing to tolerate, but can culture be shaped by the best behaviours that leaders are willing to amplify? This was a question I asked myself after hearing Dipesh Pala, IBM Agile Capability Leader for Asia Pacific, speak at Agile Australia 2016.

Last year’s VersionOne State of Agile Survey identified that four of the five top impediments for Agile adoption relate to management. Over a third of respondents cited:

  • Lack of management support
  • Company philosophy or culture at odds with core Agile values
  • External pressure to follow traditional Waterfall processes
  • Lack of support for cultural transition

The first impediment, lack of management support, needs no further comment, but when you think about it, managers also have accountability for company philosophy, pressure to follow Waterfall processes and lack of support for cultural transition.

Let’s start at the beginning, and the beginning is the most dominant style of management today, commonly described as command and control, or traditional.

Command and control was considered effective because our understanding of organisations was that they work something like the picture in this blog post.

Jurgen Appelo, author of Management 3.0 would describe this as complicated. There are many moving parts in this machine. There is also cause and effect. If one part isn’t working, it affects another part of the machine.  It almost certainly takes some time to learn all there is to learn about this machine, but, ultimately it is knowable.

Command and control was considered a way for managers to keep the machine in working order. So complicated means not simple, but ultimately knowable.

Appelo, on the other hand, describes what we know to be true of organisations today – that rather than them being complicated, they are in fact complex.

What is the difference between complicated and complex? Well, picture a rainforest and you can imagine complex.

A good friend of mine’s parents had a holiday house smack bang in the middle of a forest east of Melbourne. I found it a restful place – the river, the bird life and the amazing towering trees. This couple found it less so. So relentless was their weekend activity of cleaning bird poop off the veranda and sweeping the forest floor free of leaves, that they eventually sold the property.

A forest is a complex system. Complex systems exhibit:

  • Feedback loops – part of an output is used for new input
  • Spontaneous order
  • Hierarchical organisation
  • Emergent organisation
  • Numerosity – or an indefinite quantity of individuals

Other examples of complex systems are ecosystems, the universe, Earth’s global climate, the human brain, the stock market, a living cell and even organisations. Appelo describes complex as not simple and never fully knowable, given that too many variables interact.

The current thinking on organisations is that they are in fact complex adaptive systems. A complex adaptive system is a dynamic network of interactions. It is a system in which individual and collective behaviour mutates and self-organises, corresponding to a change-initiating event or collection of events.

Steve Denning also regards organisations as complex systems, but he remarks that it is the shift from semi-skilled to knowledge work, that means we need to re-examine the “unspoken assumptions…of the inevitability of … the practices of traditional management” such as command and control.

The management expert Peter Drucker notes that “Workers throughout history could be ‘supervised’. They could be told what to do, how to do it, how fast to do it and so on. Knowledge workers cannot, in effect, be supervised”

Perhaps the relentless bird poop cleaners and forest floor sweepers were a bit like command and control managers trying in vain to control an ever changing complex adaptive system.

How then can leaders of today enable self-organising teams to contribute and thrive within such an ecosystem? This introduction is the first of an eight part blog that tackles leadership for an Agile organisation.

Read on to understand the new four-fold role of Agile Leaders.

Agile Maturity Checks – Use with Caution!

1 Reply

Agile maturity check

Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.

At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.

My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.

It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.

Take a look at it and use with caution!

  Not yet On the way Mature
Standups We don’t run standups. We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins.
Team rhythm As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro.
Process Our way of working is painful. Process gets in the way of us getting stuff done. We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. Our way of working fits us perfectly. We have just enough process to get stuff done easily.
Speed We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. We get through stories, but there are frequently blockers, or process glitches. We get stuff done really quickly. No waiting, no delays.
Requirements Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria.
Analysis Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria
Sizing We aren’t yet sizing our work before bringing it into a sprint. Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. We have a regular rhythm of story sizing and involve the entire team in this process.
Velocity We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. We sometimes finish stories (including testing) in the sprint. As a team we always finish all the stories (including testing) we commit to in a sprint.
Sprint planning We aren’t yet conducting regular sprint planning. Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it.
Agile wall We don’t yet have an Agile story wall. We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do.
Showcasing We aren’t yet showcasing. We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built.
Retrospectives & Learning We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases.
User experience support
 We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds.
User experience integration
 We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy.
Testing Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD).
Build Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products.
Releasing Releases are extremely difficult. Our preference is to release at the end of the project. Releasing is tricky, so we aggregate as much work as possible before releasing. We have a regular rhythm for releasing. It is fast and painless
Collaboration & Communication We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response.
Empowerment – ways of working It’s the job of leadership to suggest how we can work better. It’s sometimes difficult to get traction on improved ways of working, but we give it a go. We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work.
Empowerment – product We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. Our regular cycle it to respond to learnings from customers. It shapes our backlog.
Contribution We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product.
Fun &
Celebrating
Success		 Boooooooring. We do not celebrate successes. There are some smiles about, but celebrating success isn’t something we really do as a team. We have great fun working together. We find ways to celebrate our success.