Lean Magazine #9

p. 4

Taking Project Management to the next level

LEAN EVOLUTION

p. 10

ISSUE #9 | DECEMBER 2013

MAGAZINE

SCANDINAVIA’S LEADING PROVIDER OF LEAN SOFTWARE DEVELOPMENT

Creating a framework for managers in an Agile Organization

How large and heavy become lean and mean p. 15

Getting started with Coding Dojos: Emily Bache tells you how to succeed

Bulky and slow dinosaurs evolved into slim and agile birds. Are the software companies of today ready to do the same?

Photo: iStockphoto

COVER

IN THIS ISSUE

4 10 15 20

Nomingia Beaked jaw

Agile Project Managers Bea Düring explains why there is a burning need for a new generation of project leaders, namely Agile Project Managers.

A framework for Agile Managers ‘When an organization decides to go Agile, it tends to forget about the managers and how it affects them,’ says Ola Sundin.

Try out a Coding Dojo!

Emily Bache, the author of “The Coding Dojo Handbook”, tells you how to succeed.

SAFE – It’s Alive!

A summary of a hot debate in the blogosphere about SAFe (Scaled Agile Framework).

MAGAZINE Lean Magazine is published by Softhouse Consulting.

Copyright © Softhouse Nordic AB 2013. Publisher: Anders Sixtensson.

Editor-in-chief: Gustav Bergman. Creative editor: Olle Bergman.

Design and layout: Lönegård & Co. Prepress and print: Tryckfolket, Malmö.

Additional copies can be ordered from: leanmagazine@softhouse.se. +46 40 664 39 00.

Lean Magazine c/o Softhouse Consulting, Stormgatan 14, 211 20 Malmö, Sweden www.softhouse.se

Lean ✏ Gustav Bergman Editor-in-chief

A

gile and Lean Development are currently well-established methods within the software development industry. However, there are still big challenges for putting the methods to work in many organizations. One of the most discussed of these is how old and large software enterprises with deep-rooted, waterfalllike methodologies should manage shifting their whole organization to Agile.

In this issue of Lean Magazine, we take a look at different professional functions in a traditional organization and how they can transform and evolve when their company steps into the Agile world. In ‘Agile Project Managers’, Beatrice Düring proposes how the role of project manager should evolve in an Agile transition, and how project managers can find their place in a

Unenlagia

Flapping ability

Protarchaeopteryx Symmetrical feathers

Velociraptor Caudipteryx Primitive feathers

Flexible Wrist

Eoalulavis First Alula Archaeopteryx Sinosauropteryx Flight Feathers Theropod Dinosaur Arm

Evolution Lean organization. Ola Sundin from iFACTS then shares his experience of how changing to Agile affects company line managers in the article “Who Cares about the Managers?” Ola also sketches out a framework he has developed to provide support for the management team in an Agile transformation. We wrap up this theme with some brief updates from the Agile community including the hot SAFe Framework debate and the new technique called Open Agile Adoption.

A somewhat different approach to developing your Agile organization is presented by Emily Bache who speaks about the benefit of Coding Dojos. Here we talk about working on a really basic level. Coding Dojos are a manner of helping your programmers improve technical skills.

This is of course essential in order to improve team performance, but it is often forgotten.

One of the biggest challenges the software industry faces today is how old and large companies should evolve to be more Agile in their software development. Here at Lean Magazine, we will surely return to this subject many times in the future.

Best wishes, Gustav Bergman P.S. A reminder that we have a website: http://leanmagazine.net where you can read articles directly on the web. Every now and then, we even pre-publish some content planned for the paper version. ■

TAKE PROJECT MANAGEMENT

TO THE NEXT

LEVEL!

The Agile Project Manager, the next stage in development ✏ By Olle Bergman

A

gile, Lean, Scrum and other modern methods are reshaping the entire software industry. This is creating a burning need for a new generation of project leaders, namely Agile Project Managers. It’s time for evolution!

4

SOFTHOUSE | LEAN MAGAZINE

Stage 1 Stage 3

Stage 2

In little more than a decade, Agile, Lean, Scrum and other modern methods have created amazing opportunities for the software industry to increase productivity, improve quality and, not in the least adapt to a changing environment.

But what about the business environment to which the methodologies apply – have they kept up with these project management methodology developments?

Bea Düring, PMI Certified PM and Agile Coach at Softhouse, has almost 15 years of experience in project management consulting and examines this with a critical eye. She has seen many companies struggle with the same problems when adopting Agile methodology.

Getting the development team started is just the first step. An equally important challenge is providing teams and this

Just like the monsters in the Pokémon trading card game, experience and training are necessary to take project management to the next level.

SOFTHOUSE | LEAN MAGAZINE

5

“The decision anxiety that often permeates Swedish company culture must be eliminated” Bea Düring

Bea Düring began experimenting with XP and Agile as early as 1999 and has worked internationally in EU projects that combined Agile software development and Open Source distribution methods.

At Softhouse, she coaches major customers on the transition from Waterfall development to Agile product and service development. She specialises in Agile requirements. She has been PMI certified since 2004 and has published and spoken at various international Agile conferences.

6

methodology a natural place in the business environment. This is where she sees a problem: ‘Other industries and fields are developing at lightning speed – why is project management so sluggish? Or to put a more fine a point on it: why have we let so many projects fail for so long?

Project-based thinking Bea Düring believes that project management’s heyday ended in the 1960s and that innovation has been at a standstill since.

Many of the tools in use today such as Gantt charts, work breakdown structure and PERT originated in the industrial setting of the early 1900s. They work well in industries with a slow pace of change and sustainable long-term plans. Technology develops rapidly in the software industry, however, and the market goes through unexpected twists and turns. It requires a different way of thinking, and therefore new types of tools.

Management in companies implementing Agile methods need to understand what a ‘project’ is. A good starting definition is to describe it as ‘a temporary organization to interact with a company’s permanent organization.’

‘There are many companies that have not yet been able to grasp what proj-

SOFTHOUSE | LEAN MAGAZINE

ect-based thinking and project management are all about. Management and support departments must learn to regard projects as a type of service delivery environment.’

The engine of the organization There is often talk of the Agile delivery engine – that is, Scrum team activity hums steadily along delivering fresh, functional code ready for shipping. This metaphor is useful in explaining a project manager’s role in an Agile organization. The Project Leader is the mechanic whose job it is to install the Agile delivery engine into the organization’s vehicle and ensure that it remains finely tuned. The engine’s primary task is to reach the organization’s delivery targets. Its operations also need to be synchronized with the other components such as customer support, sales, external suppliers, partner, etc.

‘In this context, it is time to define a new type of project manager – the Agile Project Manager. An Agile project manager understands how the Agile delivery engine works – that the concept is based on self-organization and undisturbed activity. In addition, he or she has the ability to manage business needs and goals, requirements, organizational models, contracts and overarching as well as ‘roll-

>>

Photo: iStockphoto/ Petter Lönegård

“Other industries and fields are developing at lightning speed – why is project management so sluggish?”

SOFTHOUSE | LEAN MAGAZINE

7

The Cynefin-model David Snowden, a researcher in the field of knowledge management, created the Cynefin model to describe the complexity and uncertainty levels in complex systems. The model is widely used in project management theory.

Conventional methods based on predictability and planning are appropriate in projects at the Simple and Complicated level. Projects at a Complex level, however, contain so much uncertainty that they can only be handled rationally through Agile methodology. The Chaotic level should always be avoided; organizations finding themselves at this level need to activate the emergency brake and solve problems.

Complex

Complicated

Probe Sense Respond EMERGENT

Sense Analyze Respond GOOD PRACTICE

Chaotic

Simple

Act Sense Respond NOVEL

Sense Categorize Respond BEST PRACTICE

Footnote: Cynefin is a Welsh word (Snowden is Welsh) and roughly means ’place of origin’ or ’place where you belong’

ing’ planning methods,’ says Bea Düring.

The complexity level dictates When is a ‘regular’project manager enough and when is an Agile project manager necessary? It depends on the project’s complexity. According to the Cynefin model (see figure), a project considered Complex demands an Agile project manager.

‘In my experience of coaching Agile transitions, there is a need for an Agile project manager when the project and delivery engine is exposed to complexity factors – as in, for example, when several teams collaborate on a release from a number of international locations.’

Requirements themselves may also lead to complexity such as when teams are faced with regulatory requirements or the need for extremely rapid alteration cycles. Other complexity factors are outsourcing and procurement – that is, the purchase of various services from multiple providers – or when a company starts too many projects at the same time resulting in staff having so much to do that nothing gets done.

8

SOFTHOUSE | LEAN MAGAZINE

Disorder

‘Several of these complexity factors exist in many of the companies we work with, and they have a cumulative effect.

An Agile project leader can achieve great things in such messy conditions by designing a comprehensive project environment providing oversight and structure,’ says Bea Düring.

The Agile Project Manager Where are these Agile Project Managers, then? The clichéd response is ‘nowhere and everywhere’. The international body PMI launched a type of formal certification in 2011, but specialized Agile project manager candidates can be found almost anywhere.

‘It is up to the management implementing an Agile transformation to work with existing project managers. To what extent is their customer knowledge and experience applicable to this new paradigm? How do we create a system of ‘do, learn, adapt’ so that we can teach ourselves? How big is the need for external skill development?’

It is important that the organization’s Agile project managers be provided with

diagnostic tools such as the Cynefin Model for their projects.

‘From there, they can design the most suitable project life cycle and build in feedback loops for continuous improvement of the process. Of course, it is important to master the conventional toolbox and understand how to facilitate an Agile project environment. Both skills are necessary’, said Bea Düring.

‘The decision anxiety that often permeates Swedish company culture must be eliminated.’

A chance for Sweden to take the lead There is great opportunity for Sweden to take the lead in introducing Agile methodology. Companies could strengthen their competitiveness. First, Agile reduces development costs since continuous improvement is built into the very concept. Second, Agile creates an environment of innovation.

Bea Düring thinks Sweden has particularly good prospects for Agile methodology success: ‘We are used to working in flat, network-based collaboration in Sweden. We are not so concerned with work-related hierarchy.’

Agile is largely based on self-organization and cross-functional working groups.

The compatibility is obvious.

She sees a major obstacle to overcome, however: the decision anxiety that often permeates Swedish company culture.

‘Many managers simply do not dare say ‘let’s do it’. Instead of starting a process by testing it out, gaining experience and learning, they kick decisions down the road. One can see this behaviour amongst many teams. A symptom of this inability to make decisions is Swedish business culture itself – a forum of meeting after meeting which everyone is forced to attend. It causes a lot of frustration not in the least amongst guests from the foreign companies we cooperate with. We need to rethink this.’ ■

ARE YOU READY FOR

Bea’s best advice to management

s p i t s Bea’

AGILE?

Do not introduce Agile methods with Waterfall methods Instead, start small-scale and test things out. Scale up as you learn lessons and gain experience.

Do not set up end goals Agile methodology is based on continuous improvement and lifelong learning – kaizen thinking in its purest form.

Provide a calm working atmosphere Let those who are best suited to do their job do it in peace. Management’s tasks are to set clear, initial conditions and restrictions that the Agile Project Manager and various teams will use as a basis and to provide support. Just as in mathematics, aim for boundary conditions.

Bea’s best advice to the project manager Manage complexity through flexibility and quick decisions It is just not possible to truly manage complex projects and environments with enhanced controls, longer planning cycles and more accurate standardization. Never forget what the word ‘agile’ means and keep blogger Michael Dubakov’s words in mind: ‘do the right things right and fast’.

Manage projects as needed Learn when to turn project management ‘on’ and ‘off’ based on whether or not it adds value to delivery. Agile project management is needed in complex projects (multi-team, multi-site, sourcing, etc).

Simpler projects or streamlined flows (kanban/andon) do not call for it.

Go from ‘deterministic’ to ‘probabilistic’ Planning skills and the planning process take centre stage, not the plan that was created in an initial phase. Agile project management is all about supporting Agile release planning and visualizing different scenarios or project developments that will most likely occur. In a complex project, all decisions are made on the basis of short feedback loops including the calculated probability of different outcomes.

SOFTHOUSE | LEAN MAGAZINE

9

Who cares about the

Photo: iStockphoto

manag 10 SOFTHOUSE | LEAN MAGAZINE

Creating a framework for managers in an Agile Organization

✏

ers?

Interview by Vadim Feldman, Agile Coach at Softhouse

Ola Sundin, Development Manager att iFACTS, is a firm believer in that great software is created by great individuals.

It takes more than just technical compe­ tence to bring out the best in those great individuals! Here he describes his ideas for the manager’s framework to his former col­ league Vadim Feldman who has experience in introducing the framework at a customer.

‘When an organization decides to go Agile, it tends to forget about the managers and how it affects them,’ says Ola. ‘As a matter of fact, if an organization wants to become Agile, it must provide the same level of support for the managers that it does for the development teams. It’s all about people. Managers are people too!’

He continues: ‘Much effort is focused on building cross-functional teams with competence from different departments. New roles and responsibilities are assigned and a new set of work practices is introduced.

This creates completely new challenges that few managers are prepared to cope with. The Agile transformation radically changes the way the managers perform their work. The managers still need to address exactly the same issues as before. Sickness, staffing and crises don’t just disappear when the organization starts working in an Agile way’.

Ola draws a comparison between the development team and the management

>>

SOFTHOUSE | LEAN MAGAZINE

11

>>

Photo: Gustav Bergman

Ola Sundin

team regarding the way they work and the level of support offered by the organization: ‘There is not really that much difference between the way the management team and the development team operate. Both teams work with impediments and requirements to fulfill the expectations on a daily basis. However, instead of delivering working software, the main goal of the management team is to deliver a working organization.’

Empowering the management team In Ola’s eyes, the greatest difference between them is that the development team receives a high level of support from the organization for their Agile transformation: ‘They receive training, coaching, and a framework to work with on a daily basis’, he says. ‘The management team does not have this privilege. There is no defined framework for empowering the management team to work in an Agile environment neither on a daily basis nor strategically’.

Ola has been working with management teams in both large and medium-­sized organizations and is often faced with the same common issues and challenges posed by an Agile transformation. The problems can be boiled down to two questions:

 How should a line manager work Ola Sundin is Develop­ ment Manager at iFACTS in Malmö, Sweden, with ten years of professional system development experience. Through the years, he has acted as product development manager, project manager, solutions architect as well as developer. Ola has an educational background in social sciences and the humanities.

and behave in an Agile organization?

 What tools and methods are needed for the managers to create an Agile environment?

During the past two years, Ola has been collaborating with managers from different organizations to try to find answers to these questions. The result is a framework for empowering the organization to provide the same level of support for the management team as they do for the development teams: ‘They still have the same tools, but the game has changed and somehow we just expect them to solve that by themselves,’ Ola says.

12 SOFTHOUSE | LEAN MAGAZINE

Setting the framework The framework is designed to aid the management team in answering five important questions to be able to deliver a working organization. The questions are What is the most important thing 

we need to focus on for this period to succeed?

How do we know if we are  successful?

How do we get there?  How do we know how we  are doing?

What is stopping us right now?  As a rallying cry for the organization, a thematic goal should be set to align people with the monthly goal. When the thematic goal is set, the next step for the management team is to try to answer the questions ‘How do we get there?’ and ‘How do we fulfil our thematic goal?’.

To answer these questions, the management team must be able to see the current development status of the organization.

This extends over everything from projects to resource allocation. Ola suggests that a visual representation of the data for each organizational area (e.g. projects) will effectively provide the management team with the current status information. He also suggests a practical approach of collecting relevant measurement data from each developmental area of interest on an A3 sheet and attaching it to the team’s whiteboard.

‘Don’t be tempted to collect and display all the data of a project. Try to find only the minimum amount of information necessary to aid the decision-making process,’he says.

Asking the right questions Ola points out that many organizations make the mistake of visualizing everything they have in a project without questioning ‘Who is this data for?’, ‘Why should anyone care about this?’ and ‘Will this help me and my management team make better decisions?’

>>

Working on three levels Operational level

The objectives for the management team on the operational level are to handle day-to-day operations. This may include activities such as incident management and organizational maintenance, e.g. vacation and sick time administration.

The framework suggests that the observed or reported incident should be handled at all three levels of operations. The management team should be able to discuss and resolve the immediate issues on a daily level or instead move the issues to a tactical or strategic level.

Napoleon at Wagram, painted by Horace Verne / Wikimedia Commons

Ola’s comment: ‘The management team should start by performing a daily Gemba Walk. Visit the development teams in their workplace and see for themselves what is going on. Communicate with the team and give them a chance to directly raise the incident they have. This will provide the much needed level of insight for effectively making decisions and assisting the teams in their daily tasks.’

Tactical level

The management team will work on a tactical level every week.

This level includes solving the incidents moved from the operational level, but also looking at the data and information collected from the organizational development areas to answer the questions ‘How do we know how we are doing?’ and ‘What’s stopping us right now?’

The incidents on this level of operations are of a more severe nature to resolve and more time should be allocated to these meetings. However, when the management team has found a solution for the incidents, they should make the effort to communicate it to the organization effectively.

Strategic level

The strategic meeting should be held on a monthly basis and is typically four to eight hours long. The focus of these meetings is still solving incidents and planning ahead based on the available data from the organization. However, the abstraction level is much higher.

Ola’s comment: ‘During a strategic meeting, the management team will try to find a solution for the incidents in the organization. The difference between these meetings and the one on the tactical level is that the team will only discuss one, maybe two items, but will commit to finding an answer during the duration of the meeting’.

SOFTHOUSE | LEAN MAGAZINE

13

“When an organiza­ tion decides to go Agile, it tends to forget about the managers and how it affects them”

>>

He explains: ‘The process of asking the right questions is essential for displaying the right information. Instead of asking what kind of data to display, the management team should ask what kind of decisions they want to make.’

The same approach can be used for resource allocation amongst development projects. Depending on the abstraction level of the management team (e.g. middle management or managerial group), different questions will be asked and the need for managing resources will differ.

‘Adapt the information and visualization techniques depending on the abstraction level of the management team,’ Ola says.

‘My suggestion is that you start with an empty board and adapt the way you visualize things in order to create the right type of conversation. It often takes some iterations to get there.’

I agree with all of this, but would like to introduce a word of caution; it is quite easy to get stuck in this phase of the framework, to focus on bringing too much information to the table as well as trying to find

14 SOFTHOUSE | LEAN MAGAZINE

the “perfect” data. One lesson I learned personally is to look at the framework as something incremental, something that will change over time and just start by using the information directly available instead of digging for more.

Creating the rhythm To optimize the framework model, the management team should perform the work needed on three distinct levels: operational, tactical and strategic (see p. 13). Each level has its own defined objectives making the rhythm of the organization, the rate at which everything progresses.

‘The key for achieving the goals set for the organization is for the management group to start working as a high performance team,’ Ola says. ‘This means that they have to start trusting each other and become comfortable with addressing the issues that really matter to the organization. They have to be able to commit to deliver the expected value and hold each other accountable for doing so’. ■

Photo: Shutterstock

Coding

DOJO �

Interview by Olle Bergman

Is your Agile organization stuck in second gear, hampered by low velocity, messy code and technical debt?

Perhaps you should start a coding dojo and work on improving your coding skills?

>>

SOFTHOUSE | LEAN MAGAZINE

15

Emily Bache

Emily Bache is a selfemployed consultant, specializing in automated testing and agile engineering practices.

Emily is originally from the UK but now lives in Gothenburg.

Company: bacheconsulting.com Blog: coding-is-like-cooking.info

Imagine a band that never rehearses, only performs concerts. Its members get more used to do what they do every day — but do they ever learn anything new? Obviously, they need to get together every now and then to practice and scrutinize the details of the music in order to progress as performing artists.

The same could be said about professional programmers. How can they ever improve their skills and get rid of bad habits if they don’t have a safe environment where they can experiment – experiment with their code, try out different languages and techniques, discuss with colleagues and have fun.

Any group of developers can have fun and learn stuff by meeting and hacking something together, and if you’re thinking of holding that kind of get-together, you could try the “Coding Dojo” format. Emily Bache has just written a book, “The Coding Dojo Handbook – a practical guide to creating a space where good programmers can become great programmers”.The book was finished in May and has attracted a lot of positive attention since.

Hi Emily! How do you think the ideas and the practices of XP are doing in Sweden today? eXtreme Programming attracted me precisely because it has very concrete advice for coders – things like writing tests, refactoring, pairing, and simple design. I worked on a project in 2000 where I think

16 SOFTHOUSE | LEAN MAGAZINE

we used 9 of the 12 practices of XP, and it was the technical ones that really made sense to me and worked well. Since then the rest of the industry has also discovered Agile, but it’s mainly the team collaboration techniques that are in XP and of course Scrum that have caught on widely. The parts of XP that require a coder to change the way they work are not nearly as widespread.

I didn’t expect that.

Why are they still important, in a time when Agile and Scrum are much “sexier”?

James Shore and Diana Larsen have come up with a model of ‘Agile Fluency’ (see martinfowler. com) based on their observations of many teams and organizations. It matches my observations too, and I think it’s useful. They talk about “one star agile” which is basically unadorned Scrum, or the XP team collaboration practices without the technical ones.This is where they put nearly half of agile teams today. The trouble with one star agile is that although you can deliver business value, and measure progress in those terms, you can’t consistently deliver at will. The ability to continue to

>>

Pho to:

Shu

tter

sto

ck

“When you step out of the Dojo, back into your production code, hope­ fully you’ll feel more motivated and equipped to write tests, clean your code, and collaborate together effectively.”

SOFTHOUSE | LEAN MAGAZINE

17

The Coding Dojo Handbook is available in pdf format from Leanpub (leanpub.com) and The Pragmatic Bookshelf (pragprog.com) and in paper format from Lulu (lulu.com).

For those who don’t like reading books, there is a video course available from Pluralsight, called “Coding Dojo:Test Driven Development”.

deliver new versions iteration after iteration requires ‘two star agile’, and for that you need all the XP technical practices. You have to invest in automated tests, refactoring, simple design, and spreading knowledge around the team via pairing or similar. James & Diana report that only perhaps a third of teams are doing ‘two star’ agile.

Without good automated tests, skilled developers and a mandate to write clean code, your codebase can really get out of hand. You become unable to deliver new functionality in any reasonable timeframe.

Which problems are we facing if we can’t understand that there is still an important role to play for XP?

Coding Dojos are an opportunity for programmers to take some time out from the complexities and stress of the production system, and just work on improving their skills. If you bring all the coders from your team into the Dojo, you can not only practice writing some really good code together, but you can have valuable discussions about what your team thinks is important when it comes to things like simple design and refactoring. You can learn a complex skill like Test Driven Development, that is usually difficult to practice in your average production codebase. When you step out of the Dojo, back into your production code, hopefully you’ll feel more motivated and equipped to write tests, clean your code, and collaborate together effectively. ■

The problem with ‘one star’ agile is that you can’t reliably deliver new software when the customer wants it, in the long term. In an agile world where you deliver a new version of the software every iteration, without any big ‘design’ phase, means it’s easy for the design and architecture to degrade. People hack together new features, without paying attention to the big picture. After a while, the team will complain about ‘technical debt’, and the bug count will start rising. Developers find it harder and harder to introduce new features without breaking existing ones.

So, how can coding dojos help to improve this situation?

How to succeed

3

OM TIPS FIRLY EM

18 SOFTHOUSE | LEAN MAGAZINE

1 Don’t force programmers to go to the Dojo against their will. Make the Dojo fun, play games with code, tackle attractive, solvable problems, so that everyone wants to be there.

Coding Dojo 1-2-3 Emily on how to try out a Coding Dojo in some simple steps “Throw in a suitably puzzling Code Kata (exercise) and a safe environment to discuss topics like design, testing, refactoring, choice of code editor, tools … and you’re away! You’ll hardly be able to stop them talking and writing code and learning from one another!

Programmers generally love the plain activity of writing code, away from managers and deadlines and production bugs. When they’ve got over their shyness, most are delighted to show others how well they can actually write code, as well as to pick up tips and advice from them.

I think there are a few aspects which distinguish a Coding Dojo from

a random meeting where a bunch of coders get together and hack on something, though. I think you’ll learn more if you add just a little structure:

* Hold an introduction and retrospective. * Write tests as well as code. * Show your working. * Have moderation or facilitation.

On a practical level, you need a suitable room with a projector, enough laptops for everyone to pair program, and a couple of hours, perhaps every week or every iteration, when coders are available to come to the Dojo. Per-

haps more importantly, you also need some people who are willing to facilitate or moderate the meetings. Those people may have to do a bit of preparation before each meeting, identify a good Code Kata to work on together, read up on the coding techniques the group will be practicing and learning about. During the meeting the facilitator will probably not write much code themselves, their role is to keep the group discussion on track, ask questions, and offer feedback. You can rotate this role among group members, or find the person with the most enthusiasm and drive, and ask them to do it. ■

with your coding dojo 2

3

When you step into the Dojo, you leave behind your status as lead developer or manager or whatever. You’re a coder, in a group of coders. Everyone should expect that sometimes they will find things easy, and they will take the role of teacher. At other times, they will need to ask for help, and take the role of learner. Everyone will write code, ask questions, and learn from others.

Make the Dojo a safe place, where people feel comfortable sharing the code and tests they’ve written, and discussing how to improve them. Everyone, not just the facilitator, has a responsibility to promote a collaborative, friendly atmosphere.

SOFTHOUSE | LEAN MAGAZINE

19

A helpful framework, or a RUP monster from the past?

Godzilla, King of the Monsters! Jewell Enterprises Inc. 1956

This autumn has seen a lot of heated chatter on Agile blogs about SAFe (Scaled Agile Frame­ work). SAFe is ‘an inter­ active knowledge base for implementing Agile prac­ tices at enterprise scale’ developed by Dean Leff­ ingwell and some fellow Agile practitioners.

20 SOFTHOUSE | LEAN MAGAZINE

SAFe is probably here to stay nonetheless The majority of bloggers questioning SAFe admit, however, that it is indeed cunningly designed to fill a very strong market demand from senior management in large corporations who want a blueprint for their Agile transitions. Furthermore, the tool industry and many consulting firms see interesting opportunities in using SAFe as a means generate more business at larger corporations. It seems that many experts in the Agile world are convinced that even if they do not like SAFe, they will have to learn to live with it. ■

a Links: Scaled Agile Framework website http://scaledagileframework.com/ unSAFe at any speed by Ken Schwaber http://bit.ly/unSAFe-at Kanban – the anti-SAFe for almost a decade already

by David Anderson http://bit.ly/Kanban-anti Method Wars: Scrum vs. SAFe by Ian Mitchell http://bit.ly/method-wars A critical view on SAFe by Dominik Maximini http://bit.ly/critical-view

Go to Softhouse’s webshop!

http://softhouseeducation.com/butik

Influential Agile professionals are sceptical Several influential Agile names are sceptical, however, and they have expressed considerable criticism regarding SAFe in blogs and elsewhere. Ken Schwaber, one of the co-founders of Scrum, wrote a heated blog entry during the Agile 2013 conference in Nashville (see link below). Under the title ‘unSAFe at any speed’, he calls the SAFe people attending the conference ‘the boys from RUP (Rational Unified Process)’, and said that SAFe is merely a new attempt at a simple, one-size-fits-all approach after RUP’s profound failure.

During a hot August and September, there were also critical articles posted by David Anderson, ‘Kanban – the antiSAFe for almost a decade already’, Ian Mitchell, ‘Method Wars: Scrum vs. SAFe’, and Dominik Maximini, ‘A Critical View on SAFe’. Dean Leffingwell and others from the SAFe community responded to some of the criticism by saying that SAFe has been misunderstood in that it is a completely different creature than RUP; ‘it’s not a ‘process’ – it’s a framework’.

Order free copies of Lean Magazine, popular brochures like “Scrum in Five Minutes”, buy items for Softhouse’s famous Scrum Master Kit like Planning Poker decks, Burndown charts and more.

Photo: iStockphoto

SAFe addresses many of the concerns that top managers in large corporations have had about frameworks like Scrum, namely issues above the team and project level such as Portfolio Management and Release Planning.

It is also welcomed by the tool industry who has seen a need for a larger framework standard that can guide their customers on how their tools should be used in larger organizations. Several tool vendors such as Rally Software have also officially stated that their tool suite is aimed at supporting SAFe.

Management 3.0 “Let the flow manage the processes, and Illustration: Petter Lönegård

not let management manage the flow.”

– Taiichi Ohno

– how to deal with your crappy organization

W

hen you see the playful graphics at the management30.com website, you realize immediately that it is a starting point for those wishing to start thinking in new ways. In short, Management 3.0 is a set of leadership principles and practices inspired by complexity science and systems thinking. Jurgen Appello, a software engineer and handyman from Delft, Holland who now calls himself a creative networker, is the man behind this concept.

Open Agile Adoption – using Open Space and applied anthropology to facilitate Agile implementation

Why do so many Agile implementations come up against so many setbacks and end up in some sort of semi-waterfall failure?

Dan Mezick, one of the men behind a new technique called Open Agile Adoption, says that this is often due to Agile implementation being introduced as a mandated, non-negotiable prescription. This at its best reduces engagement and at its worst leads to resistance and hostility.

Open space meeting

The Rite of Passage

Iterations

Open space meeting

Open Agile Adoption’s recipe for success is to repackage an Agile transformation into an invitation rather than a mandate. This is believed to lead to more engagement as the people affected by the Agile transformation feel that it is their project and nobody else’s.

In practice, the Open Agile process begins with an Open Space Meeting where everyone is invited to take part in the transformation. It is followed by a several-month long “Rite of Passage” (an anthropological term) where teams are encouraged to experiment and play with Agile techniques and subsequently discuss them at retrospectives. The process is finalized with a second Open Space Meeting.

The Open Agile Adoption technique contains many interesting ideas. If you would like to read more about the whole program you can do so here:

a

http://newtechusa.net/open-agile-adoption

22 SOFTHOUSE | LEAN MAGAZINE

The purpose of Management 3.0 is to “transform organizations into becoming great places to work” by organizing workouts, hosting events and, most importantly, offering courses held in a number of countries in Europe, North America and Asia.

Jurgen Appelo’s number one advice to organizations who want to improve their Agile management is to remember traditional learning methods: ‘Read books. What you should be doing is already discovered, already described, and already picked up by your competitors.’

Jurgen Appelo’s most recent book is ‘How to Change the World: Change Management 3.0’. It answers the question “How do I deal with my crappy organization?”. He is also the author of ‘Management 3.0: Leading Agile Developers, Developing Agile Leaders’.

THE COLUMN

HAPPY CLUTTER

– messy and lean!

Illustration: Petter Lönegård

Tina Lenshof, M.Sc., is a software consultant at the Softhouse Malmö Office. As a CM, she spends most of her time supporting developer teams and maintaining the agile processes.



I have been an executive manager for the company ‘Happy Clutter’ for about two years. Our first business venture, the Two-Year Old, is well-established and our nice but messy family life production continues at full speed. The Board, that is my husband and I, have therefore started to discuss future expansion of the enterprise.

It is admittedly a little messy at times. The amount of muda (futility, waste), both administrative and literal in nature, has been considerable.

We have managed to tick off all seven of the classic forms of muda plus a handful we had never known existed. We have therefore decided to start implementing Lean in the family and introduce a kaizen method.

We are certainly not the first to come up with this idea. Truth be told, we have acquired a manual to help us get started with forming our own Lean version. It is called “From Frustration to Flow with Lean@home”. It was written by Eva Jarlsdotter who has worked at both AstraZeneca and TeliaSonera.

Lean@home is run from the heart of the home, the kitchen. We have, of course, set up a kanban board. We use it to fill in weekly tasks plus a backlog of activities at work, preschool and in our private life.

The kanban board also has an area reserved for larger projects such as spring cleaning and home renovations.

We have also collected the following important items in connection with the board: * markers, tape and post-it notes * bills * the weekly meal plan and its respective recipes * a packing list for when we travel on weekends (this has been rewritten several times; we finally decided to save a copy) A Lean worker is always on the lookout for problems and sub-­ optimal conditions, and there are plenty to be found in laundry management. We have taught the Two-Year Old to do the laundry, so we now have no excuse to put it off just because he is at home. The washing machine is the perfect height for him to put in and remove laundry articles (and light it up and make it beep and roar and spin). The wardrobe used to be a weak link in laundry logistics, but we have now set up new shelves and repainted it. The next step is to rearrange the laundry room and include marked laundry baskets – seiri is da shit!

Food preparation is also an area where muda features prominently – transport, purchasing errors (especially when shopping is done on an empty stomach) and food past its due date. We address these problems by purchasing bags of grouped ingredients in a weekly meal plan.

The contents are inspiring, and meals are easy and quick to prepare.

Last but not least, we try to practice mindfulness. Lean is all about learning to focus in order to make better everyday decisions with a vengeance. But there is also the added advantage of being more in the moment with the Two-Year Old whether we are cleaning, doing laundry, playing or spending quality time together. ■ SOFTHOUSE | LEAN MAGAZINE

23

What

MOST IMPORTANT BARRIERS TO FURTHER AGILE ADOPTION

are the impediments for large organizations to implement Agile, and what can you do to get rid of them

52% 14% Budget constraints

35%

Trying to fit elements into a non-agile framework

13% None

Ability to change organizational culture

22%

31%

Perceived time to transition

41% General resistence to change

Management support

26% 26%

Customer collaboration

Confidence on ability to scale

14%

?

Project complexity

33%

Availability of personnel with right skills

MOST IMPORTANT GREATEST CONCERNS ABOUT ADOPTING AGILE Lack of up-front planning Loss of management control Management opposition Lack of documentation Lack of predictability Lack of engineering discipline Dev team opposed to change No concerns Inability to scale Regulatory compliance Quality of engineering talent Reduced software quality

9%

14% 13%

20% 18% 18% 17%

27% 26% 24%

31%

34%

MOST IMPORTANT FACTORS TO FACILITATE AGILE ADOPTION

23%

Executive sponsorship

18% Training programs/ workshops

13%

Implementation of a common tool

12%

Internal agile support group

10%

Full time agile coach

8%

Contracted consultant

Source: 7th annual state of Agile Development Survey by VersionOne