Presenting techniques for visibility and effectiveness at the Global Scrum Gathering Prague

Deciding on what to build is one of the most important decisions software companies need to make. Understanding when those are the wrong decisions is the next most important. There are many tools that can be used to help with this, but sometimes tools are solving the wrong problems and visualisation is the best first step. In fact, if you don’t know that you are sub-optimising, then how can you make the right decisions on a global level.

Information Radiators On A Portfolio Level

Building every idea and small feature is impossible, building features that no one is interested in is wasteful. How can visualisation help companies free themselves from the waste and move to the next level.

The talk we will present at the Global Scrum Gathering in Prague will focus on the use of visualisation at a portfolio and program level as a tool to help understand what is in a system and create visibility of what sub-optimizations are happening and how the work is currently being processed.

Saremo presenti agli Italian Agile Days 2015

Anche quest’anno agile42 sarà presente con piacere agli Italian Agile Days 2015, il più longevo evento della comunità Agile italiana. La conferenza si svolgerà sabato 7 novembre a Brescia e sarà preceduta da una giornata di workshop.

Io presenterò la sessione Metriche? Ne bastano solo tre, anzi una in cui discuterò della quantità di informazioni a disposizione di una organizzazione IT: tecnologia, processo, persone, servizi…

Ma quali di questi dati sono veramente importanti? E come dovremmo usarli?  La buona notizia è che in generale solo pochi sono necessari, quella cattiva è che ogni contesto è differente ed è necessario capire caso per caso quali hanno senso e perché, e questo cambierà con il passare del tempo.

Dati, metriche e KPIs se male usati possono generare problemi e portare a cattivi comportamenti. E’ facile interpretarli in modo errato, così come è semplice “barare” con numeri e statistiche. L’approccio Agile e Lean ha molti argomenti di discussione a proposito dell’uso dei numeri.

Spero di vedervi a Brescia!

Sponsoring Product Camp Berlin 2015

We are happy to be again main sponsor of the ProductCamp Berlin. It is the first and only unconference for product managers, product marketing managers, entrepreneurs and others with passions for product, online and IT, in Berlin, Germany. ProductCamp Berlin 2015 will be held in October at the Evangelische Schule Berlin Zentrum. Around 200 participants will come to share, learn and network with other product people. Following the Barcamp idea of “no attendees, only participants”, we will actively engage in a day of workshops, discussions, networking and learning.

Product Camp Berlin logo

This is one of the most popular events in Berlin, a growing startup hub in Europe. There are still tickets available, jump to the registration and see you at the event!

Our visit to the Menlo Innovations factory

“To end human suffering as it relates to technology” – The software industry has done a huge disservice to its users, by assuming that they are not as competent as the people who built these products. The success of “… for Dummies” series of books is proof and unfortunately also acceptance of this belief. The greater purpose that Richard Sheridan and James Goebel are chasing has taken decades for them to practice, in their journey many have joined, left and then some joined again (‘boomerang Menlonians’) at Menlo Innovations. The company is driven by a higher purpose that challenges common assumptions that we have taken for granted and explicitly pursues “joy” for the users that use software products developed at Menlo Innovations. Apple and other companies have proven the value of “experience” and the economic benefit of selling “self-expression”. This attachment of personal expression to the products we use is nothing new; for ages people have used artifacts and trinkets that have served as medium of expression of our identities. Our notions of software systems and their utility is firmly rooted in its efficient functional utility. Perhaps in the days of limited memory and low level programming languages, this may have been the need of the times – to complete account balance transactions for all account holders overnight. We have clearly outgrown our expectations of and from software products. It is no wonder that products that delight are winning our hearts and our money.

agile42 team with Richard Sheridan at Menlo Innovations

This pursuit to end human suffering for users of products developed at Menlo, has extended into “the software factory” that is Menlo Innovations. It is so strange to hear about the physical space where Menlonians work to be described as a Factory. My notions of a factory implants an image of oppressive management and underperforming work force, continuously in a struggle within a de-humanized, mechanical environment. One would expect to see pursuit of ruthless efficiency, but instead there is active pursuit of “joy” in a systematic, methodical manner. During our visit it was obvious, I felt it – the culture. Living, breathing, morphing, taking shape in the form of experiments that are continually attempted here. The high degree of engagement from Menoloians working in pairs, or more like teams made up of pairs, creates this industrial hum. Much like, one does not ever say “lazy bee”, you would never say “disengaged Menlonian”.  Gallup polls have steadily charted employee engagement via surveys, reporting 68.5%  of employees are either “actively disengaged” or “not engaged”. Discovering a factory of engaged people was, well, a joy to watch.

Is there such thing as continual joy? Could one perpetually be in a state of joy? Of course not. The joy is in the fight. A good fight. A fight worth taking on. For Menlonians this is to end human suffering as it relates to technology. In the use of products developed at their software factory. I strongly contend that it is their “Greater Cause” that has given birth to their culture and it is this constancy of purpose over the last 15 years, that has defined and shaped their culture. This “greater cause” is the drive, the fight, that continues to breathe life into what we experienced for a day at Menlo.

It is too simplistic to take a look at Menlo and describe it in terms of its practices such as pair-programming, strict 40-hour work weeks, babies in the workplace and the oft-heard “hey Menlo … ?” questions.  Describing it in term of patterns, such as visual and tactile information radiators, is equally naive. It is similar to having seven blind people feel different parts of the elephant and miss the majestic beauty of the being. There is much at play, more than what any human or any erudite committee of experts can ever comprehend. One would never describe oneself by the clothes (s)he wears, the artifacts (s)he possesses, the house (s)he lives in, the people (s)he befriends. All these are extensions of choices manifested through what is visible. While these practices and patterns give form to what is understandable, there is much that is ephemeral, this effervescent essence escapes recognition, yet it can be felt. Is this what we call culture?

Every body works in pairs. This is the norm at Menlo, when it comes to its development and test teams. While other roles, such as Project Managers & HTA (High Tech Anthropologists)s do not always pair. It is an explicit rule at Menlo that no one can write a single line of production code alone. Only a pair – two people working as one unit – is allowed to write production code. This simple rule, sends a strong message – “You are not alone.” This simple rule explicitly builds “help” into its organizational DNA.

A board at Menlo Innovations factory in Ann Arbor, Michigan

Through their Extreme Interviewing process, Menlo selects people who are good at the Kindergarten skills of being able to share, care and play with others. This self-selection of people with like inclinations strengthens their core culture. Folks that make it through the interviewing process, which includes a group interview (in pairs, of course) followed by both a 1-day trial and a 3-week trial, have been through the experience of being a Menlonian prior to making a long-term commitment. Both parties, the company and candidate-employee are in a dating period, gradually increasing inter-personal involvement. The company has about 20-30 developers that work in pairs. The pairs are assigned by a Project Manager. These pairs float between various client projects. This communal handling of client projects by the entire development staff ensures that there are no cool or dull projects. Everybody gets to work on every project. It also leads to dynamic load management to match cash-flow constraints/capabilities of client projects. And of course, there is almost never a case of dependency on a single person to progress through tasks. The pursuit of bringing “joy” in the use of software products is technology agnostic. Their mission makes technology stacks accomplices towards their greater cause and not the ball and chain that anchors developers to lifetime of java. This fluidity in use of ever changing technology stacks is immensely rewarding for programmers’ personal growth and future career prospects.

The Hi-Tech Anthropology® Group is a dedicated group of professionals that are most directly and visibly connected to their greater cause. It is an established practice to go and observe the end-users in their native context. To abstract personas of their typical users, map user workflows and present low-fidelity paper prototypes as options to users and gauge their engagement/joy in use of their yet-to-be-developed product. As one HTA professional shared, in the beginning, they purposefully isolate themselves from the technical feasibility of their designs and prototypes. This freedom keeps the HTA group focused on the user needs. The user only cares what the product does for them, not how it does what it does. Early convergence forced by technical constraints often does a disservice to the exploration of other options that could meet users’ real need: bringing joy in use of the product. For a product the purpose is stable and long-term. The requirements evolve and morph with time and change in the marketplace. But a person with a problem that needs solving always stays steady. Honing on the person’s needs is the single magical stroke of genius that shapes the rest of the practices.

The HTA, after working out possible solutions presents options to the implementation pairs. These pairs estimate their story cards, which then get scheduled and prioritized by their customer. Through many years of iterative improvements they have a current definition of a story card, that captures essential information of customer value, project code, estimate (cost), and additionally relevant notes. While anyone can recommend new story cards, these must make sense to the customer and the value of implementing the story card must be apparent to the customer. The onus of proving the worth of a story card to their customer lies on the person/pair that authors the story card. The project managers liaise between the customer and the implementation team, and also manage other project management essentials such as billing, burn rates and so on. The PM’s are customer advocates and they represent the voice of the customer. Their main method of engagement with the customer and managing customer needs is through a “planning game”, where, based on hourly estimates of story cards, the customer fills in project cards. These project cards represent 40 pair-hours (80 person hours) of total effort. Given the time it takes to participate in their daily scrum, planning and review meetings the pairs estimate for and plan in 32 hours pair-hours per project card. Depending on the expected burnrates the project manager will schedule in as many project cards (pairs) for the next weekly iteration as required. Simple overloaded interfaces is a sign of mature architecture. The project cards not only provide full control of story card scheduling into their customers hands, but also acts as a pair scheduling system. This overloaded behavior of the “planning game” interface accomplishes in one session, that in many other organizations will involve many soul-sucking meetings.

Menlo has turned their factory into a must-see destination for Industrial Tourists. This is perhaps the wave of our times. Wrestling with complexity that advanced technological improvements have forced on us since the Second World War has triggered an avalanche of challenges that our renaissance mind cannot comprehend. This desire to be able to comprehend, to understand, is the single greatest limitation that hinders exploitation of opportunities that are for the taking. For Rich and James, what started as a way to share their pursuit and resultant factory, has turned into a multi-million dollar business opportunity. People like us pay good money to come see the Menlonians at work. Who would have thunk!. There is a “market” of industrial tourists that want to see it to believe it. There is a market for suckers who want to copy practices and patterns and miss the essence of what it is to be comfortable with uncertainty.

A leadership trait that can be best described as a negative-trait, that is in terms of its absence as opposed to its presence, is that of “seeking to understand”. There is a clear lack of any attempt from Rich and James to take control and understand the mechanics of how the people in the company works. There is however the strongest desire to “control outcomes”. This may seem paradoxical, but that does not mean it is not possible. To say it in other words, James and Rich are extremely curious and have strong preferences for “good” outcomes, however there is a matching lack of interest in directing how the outcomes come about. During the day, I witnessed many people reaching out to James, to bounce their ideas off him. There was also one instance when an employee insisted that she had information about a project that James will be “most” interested in. In many organizations management is starving for real information, let alone to be alerted of new and interesting information. How do Menlonian’s know what their founder would be “most” interested in? Is there a Jedi mind trick at play here? I strongly suspect that consistency of moral and ethical leadership by the pair of founders has engendered a feeling or a knack for ‘knowing’ – between people who have worked together to share information of “most” value to each other.

This description of our (agile42) visit to Menlo is my perception of the events that I witnessed. I am certain that there is a lot that my mental models and filters simply could not perceive. Perhaps it was all just a charade! In knowing my limitations and consistency at being wrong. I know that as days and years pass by I will get progressively less wrong. A new revelation always awaits a learning mind. A constant echo in my poor mind will be the operating mantra at Menlo, the Menlo Way: “Simple, measurable, repeatable and visible, structure and a process that focus on human relationships that feed and nurture human energy”

I am very grateful for this site visit, organized by agile42 as part of their annual International Coach Camp.

 

3 Reasons Why Agile Training Is Not Enough

I just got off the phone from talking to a potential client about their agile transformation. They are looking to adopt agile practices across 4-6 teams, they have some idea of what they want (Scrum) and why (to speed up time-to-market), and are looking for some training. Just training. With the belief that that will get the teams to be agile. Please, no.

As a coaching company, of course we believe in coaching. We’ve  already written about  – why we train – as part of that coaching strategy. And there are many times that just training is an excellent strategy for an organization – to inject new energy into the teams, or bring new cohorts of developers up to speed with agile – all great reasons to just deliver training. But I get so frustrated when teams start their agile journey with a training and a handful of books or blogposts to go on.

Don’t get me wrong – just training works. Almost too well. We know many agile teams that have launched successfully from a single training session. The teams are happy, and delivering working software. Management is satisfied. Product owners are getting product out of the door. So why am I so glum?

Here are 3 reasons training alone is rarely a good idea.

1) Missed Opportunity

Agile should blow your socks off. Teams that truly adopt agile outperform traditional product delivery by a lot. Unfortunately, many teams that use training to launch agile teams succeed, at least in comparison to their old way of thinking. They used just enough agile practices to be able to deliver working software with a little more transparency, and could make a case that agile was working. The frustrating thing is that they were barely in first gear. We often hear these companies see agile as an alternative to more traditional, sequential delivery methods, instead of a replacement. They see the two as similarly effective, and talk about projects suited to agile and projects suited to waterfall. This is so frustrating given the opportunity agile represents. It feels like driving a Ferrari but only ever in first gear. You’re moving, but what a wasted opportunity!

Kid cars

Let’s take the car-driving analogy a little further. I drive a Ford SUV. It’s a great car, and gets me from A to B exceptionally well. No complaints. Mileage is good, the ride is good, and I can transport my entire family in comfort. I’d like to drive a Tesla Model X. Same car – an SUV. And I can match the performance of the Ford SUV without too much difficulty. So comparing the Ford with the Tesla, I might argue that they are equivalent. And I might then think about which trips to use the Ford on and which to use the Tesla on. But this is to ignore the innumerable benefits of one option over the other. In so many ways, the Tesla is incomparable to the Ford. Whether on performance, fuel efficiency or plain cool factor, the Tesla beats the Ford hands down. There is no comparison.

Those agile teams that reproduce similar or marginally better productivity than their old teams suggest old and new processes are comparable, when in actual fact, Agile practices will take you so much further so much quicker. But if you never get out of first gear, you’ll never find out.

2) Burned Bridges

People have a limited patience for change. Asking teams to try agile ‘one more time’  is going to meet stiff resistance or simply be ignored if there are too many bad experiences. Therefore, every attempt at change is important. A poorly executed transition creates a barrier for the next attempt. It’s one reason our annual pilgrimage to get fit and healthy is so hard. We have so many failed experiences to look back on we simply don’t have the energy or capacity to make it work ‘this year’.

One client we worked with had trained the entire development organization and ‘launched’ many development teams.

By the time we hit the ground, there were a large number of teams that had tried agile, found out how hard it was and, for the most part, stepped back into their old ways of working. They were frustrated when the promises made in training failed to materialize quickly, and lacked the experience to be able to continually grow towards a more effective and productive solution. Those promises remained elusive and many people lost the belief that they could ever be achieved. Most of these teams rolled back to where they started from and stubbornly pushed back at agile practices introduced later on.

Teams have a lot of trust in decisions made, such as to adopt a new way of working. But each time these efforts fail to deliver, that trust is eroded and a barrier is created to future efforts. Training alone can leave teams with a poor experience that becomes that much harder to overcome in future.

3) Practice Makes Perfect

Experience counts. Agile is based on sensing and responding to situations. Each situation is different, and every response is based on applying well-defined agile principles. The art of continual learning is not a formulaic what- to- do-when, but how to tell whether what you did worked or not. Training is very effective for communicating how predictable, linear systems work. If you introduce a new accounting tool, or a new expenses system, the likelihood is that a training, both in person or virtual, will be enough to get everyone up to speed and using the new tool or process. Think of this as a one-to-one relationship – where possible actions are clear and unambiguous, training is sufficient.

Now consider learning to drive. We would never consider training alone to be enough. Driving is a completely different skill. We need to learn the fundamentals, and practice the core skills. But real competence only comes with lots of practice and, quite frankly, a little experience of what can go wrong, hopefully in the form of a safe-to-fail experience. Agile is much the same. Just like in a car, the fundamentals appear to be straightforward. A pedal to push here, a lever to pull there, and a steering wheel by which to steer. And just like learning to drive, agile has a tendency to throw surprises at you, and having a co-pilot with you in those early days can be invaluable in successfully learning how to use agile principles and practices in the workplace.

What next?

As agile software development becomes the norm in many organizations, at least in expectation if not reality, more and more teams are seeking training to kick-start their transformation. In many cases, training is the right answer. There are good reasons to refresh knowledge and expertise. It’s one reason I still look for time management classes and books; a refresher of basic principles and a look at latest practices helps keep our skills sharp and relevant. I’m also always impressed at how many people I talk to understand how and why to properly manage an organizational change such as agile adoption. So perhaps this article is aimed at the budget holders and managers who mandate a change to agile, but then short-change it through a squeeze on resources, eventually settling for just a little training. Recognize why the results you expect might be slow in coming.

Photo iStock

A message from AstroSamantha

We have followed in the past few months the mission of Europan astronaut Samantha “AstroSamantha” Cristoforetti, not only for the great scientific value of their work aboard the International Space Station but also because the mission number 42 led the crew to pose in full HHGG costumes for the mission poster. Also, Sam revealed herself as a proper geek with her sci-fi references and she brewed the first espresso in space while dressed as a Star Trek character.

Now Samantha, “adjusting back to being an Earthling on our beautiful spaceship Earth”, gives us the most important of messages: Don’t Panic.

Samantha Cristoforetti

Photo of ESA astronauts Luca Parmitano and Samantha Cristoforetti edited and published by Duncan Wilcox on Twitter.

Esteem and Estimates (Ti stimo fratello)

L’approccio #NoEstimates sta catturando molta attenzione e ha dato vita a discussioni molto accese in rete. Torniamo dunque a parlare di stime, tramite le slide presentate a Better Software 2012 che riprendono alcuni dei temi chiave sull’argomento.

Ci sono aspetti sistemici: il contesto influenza le stime e le stime influenzano il contesto; chi fa le stime non è sempre chi le usa (anzi quasi mai) e ciò influenza come e perché nascono (male), come vengono usate (male) e le disfunzioni che ne conseguono. Tendiamo a usare le stime nell’illusione di sfuggire all’incertezza e alla complessità che sono invece intrinseche alle attività di sviluppo prodotto.

L’ideale sarebbe non stimare ma se si è proprio costretti… Si esaminano allora forecast e commitment, timeboxing e flusso, metriche e contratti.

E per chiudere un richiamo ai valori e ai principi alla base di un uso sano delle stime: trasparenza, condivisione, rispetto.

Introducing the Team Coaching Framework

A lot of things are happening at agile42 and we are happy to share with you the latest addition to the set of tools we use to coach and train organizations that start an Agile transition or want to improve their Agile workflows.

The Team Coaching Framework™ (or TCF) creates a structured approach to coaching which aims at improving team performance by providing clear guidance and structure with the help of the coaches. It allows for members of an organization or the larger professional community to share everyone’s experience and improvements.

The TCF defines Coaching Tools, instruments that a coach can introduce in the work of a team to change its behaviour. An Assessment allows the coach to measure the maturity of a team, and through Coaching Cards she can focus on a specific behavioural goal for it. Measurements help understand which Coaching Tools are the best fit to improve the team.

The list of working Coaching Tools that a professional coach may use is very large, and the TCF provides templates of Coaching Cards that help understand which Coaching Tools to use and how to apply them.

agile42 coaches use the TCF during Assessment and Coaching with teams at clients, as part of our Agile Transition and organization improving efforts. The TCF is also used and taught during the Advanced Agile Team Coaching Course we launched in 2015 and you may have seen a brief recap at our workshop during the Scrum Gathering Berlin last year: the illustration here is the beautiful graphic recording of that event by visualization maestro Benjamin Felis.

 Effectively Coaching Agile Teams at Scrum Gathering Berlin: graphic recording by Benjamin Felis

 

agile42 is also developing a Team Coaching Framework App: a tool to save, edit and share Coaching Tools, Coaching Cards and common metrics to measure the effectiveness of the coaching. Everything is stored for later reuse by yourself and other coaches in your organization. It lets a new, relatively inexperienced coach pick the right tools and metrics to quickly get up to speed, and to get advice from more experienced coaches.

The App will also include software allowing coaches to make online Assessments of their teams, and other professional tools.

If you decide to share your work with the larger community, you will receive feedback and improvements. The system gives you full control of your intellectual property.

The App is currently in beta testing by invitation, for further information please contact us.

Meet The Coach: Dave Sharrock

Q: Can you summarize for us your career path and how you came to be an Agile coach?

I’ve worked in product development for over 15 years, continually looking for the best way to help software development teams develop awesome software.  I’ve re-structured countless production teams, and scaled productivity many times, project and program managed projects and teams to deliver on time and on budget.  I finally found myself as a product manager for a startup in Munich.  

At Christmas time, after months of frustration, I wrote a memo to the COO/CEO explaining why IT was such a problem and outlining in detail what I saw was wrong and why we needed to improve IT.   I was called in over the Christmas break and informed that the CTO was moving on to another startup (a decision made before my less-than-diplomatic memo) and that, since I had such a big mouth, I would now be leading the IT group.  

And so began my agile journey…

I learned a lot of things of things about tact and diplomacy (how to have some for a start) and recognized that the IT group could not improve without some help. Searching for process improvement specialists, we came across an agile coaching firm, and the rest as they say is history.   To be fair, we felt we were a long way from being in a good enough position to become agile.  So agile, though a distant goal, was not considered an option at this early stage.  However after talking to Andrea Tomasini, the founder and principal coach at agile42, we decided to move forward with them, and turned the IT group around.  The only thing I did right was bring in the coaching firm and stay out of their way.  

We started from a place in which we had painful releases every 3-4 months, with anywhere between 8-12 hours of downtime and innumerable hot fixes.  Six months later, the engagement had a positive ROI.  Eighteen months later, the group was the best performing department in the company, with a release every two weeks, with one hour of downtime, two if there were major database changes.  Following the 2008 crisis, when the startup had to scale back, I chose to leave the company and was the only executive to do so, leaving behind a smoothly running IT group that delivered what was needed quickly and effectively. I later joined agile42, the agile coaching company we hired, to head up North America, launching my coaching career.

Q:  What are your top 3 tips for Agile managers?

Fight the urge to intervene.  Managing any team is hard and leading is often interpreted as stepping in and showing teams how it’s done.  Actually leading teams is the opposite.  It’s not about intervening, but about nurturing the latent skills of the team.  Asking clarifying questions and creating an environment with lots of feedback mechanisms to help guide the teams.  
Get used to uncertainty.  There is a comfort in having a solid, well-defined plan in front of you.  It’s easy to stand in front of stakeholders, and point at it and talk confidently about delivering to plan.  But software development is riddled with uncertainty and the plan is little use in the long run.  Getting used to a level of uncertainty takes time, and is hard to achieve.  Once you’re there, you probably can’t remember why you ever thought well-defined, locked-down plans were helpful.  
Only accept working software.  The key to working in a rapidly changing environment is to have regular stops to review where things are.  And what is reviewed is important.  Partial delivery does nothing to mitigate the changing environment. Partially completed work still carries risk when things change.  Only completed, working software has any value in these checkpoints.  Insist on regular reviews of finished, integrated product.  Activity has no value – we know the teams work hard. Only completed work counts.  

Q:  What is the main inspiration for what you do?

Making work rewarding.  I believe work should be something you do because you love it.  Being paid for what you love to do is much better than being paid for what you have to do, and makes leading teams an inspirational responsibility rather than a chore.  Unfortunately, I think we have lost decades in which software has been managed or controlled rather than nurtured and inspired.  Applying agile principles and seeing the dramatic difference in productivity and fun on truly agile teams is a powerful motivator; seeing the light return to someone’s eyes, and getting pulled aside to hear stories of how much more motivated and interesting work is.  

Q: What have you seen lately that is interesting and new?  

Managing agile teams and organizational leadership structures.  The practices and application of Agile and Lean principles and values are important and continue to morph and grow.  From the Lean Startup to agile frameworks like Scrum and Kanban to DevOps and continuous delivery.  But where I see the most new and interesting thought leadership is in agile management and agile leadership.  It won’t be called that, but there are exciting developments for what it means to lead agile organizations.  First, managing agile teams and agile product delivery requires different thinking to that of our traditional managers, epitomized by MBA-trained executives (speaking as an MBA graduate myself).  Value delivery requires more than paying lip service to accountability and customer value.  Second, leadership of the most creative and powerful organizations is increasingly moving away from hierarchical structures.  What it will look like is still open to interpretation, but things are definitely changing.  

Q:  Favourite non-fiction book and why?

I’m going to go with two here.  I read all the time, and revisit some books and use others to get a leg up in understanding.  Here are the two I’m taking off my bookshelf the most at present.  

Current reading for a leg up – Reinventing Organizations. Understanding the strengths and weaknesses of different company structures holds the key to the next generation of successful corporations.  In Reinventing Organizations, Frederic Laloux takes us through the history of organizations and their leadership structures, painting a picture of where the most enlightened leaders and entrepreneurs are going.  This book is one that challenges me to sit and think about how this changes how we work both within agile42 and with our clients.  

The book I revisit the most – The Principles of Product Development Flow.  Agile may be hitting mainstream, but still hasn’t begun to be explored.  I liken it to the discoveries of the African continent in the 1800s.  A good understanding of broader geography and some of the potential of the subcontinent, but no real detail.  We knew about Victoria Falls and the Congo, but little else.  Well, if agile is the African subcontinent, Don Reinertsen’s book is the closest to providing a detailed map of the interior and of how Agile and Lean might develop in years to come.  Essential reading.

The 2015 State of Scrum report

The 2015 State of Scrum ReportThe Scrum Alliance just released their updated State of Scrum report based on their investigation of the industry. The survey uncovered findings that not only reflect where Scrum is today, but what we can anticipate it will look like tomorrow. These include who is practicing Scrum, how they are practicing it, success levels associated with Scrum, and plans for its continuing use.

Report statistics provide intriguing insights and information such as:

  • 87% say Scrum improves teams’ quality of work life    
  • 81% believe certications improves the practice    
  • On average, Scrum is successful 62% of the time    
  • 95% will continue to use Scrum

The report is free to download from the Scrum Alliance site.