Just Start!

I have heard many reasons why a new team should wait to start “doing” Agile.  Recently, I was asked to help a group who was struggling to get a Scrum team started.  They had real obstacles to overcome, but waiting wasn’t helping them.

This group was part of an IT initiative to develop a business intelligence program for a large energy company.  The existing processes were highly inefficient and wasteful.  The losses were in the ballpark of $1M/day.  There was a long history of failed solutions.  Needless to say, this was a critical project.

Those of us who understand Scrum well know that the more critical a project is, the more urgent it is to get a team up and running as early as possible.  Unfortunately for this group, there was a great deal of cultural inertia from the IT management holding them back, including chronic distrust between IT & business leadership.  IT management perceived Agile to be a risk and a threat.  They were tolerating it as a “pilot project”.  They wanted to be sure that when Agile failed, they would not be left holding the bag.  Their solution for self-preservation was to insist on getting the architecture of the system in place before the team started to work on features.

The only developer that management trusted with the initial architecture work was also extremely busy working on other projects.  This individual and several other people slated to be on the new Scrum team were tied up working on change requests for a Waterfall project with no clear end in sight.  It seemed impossible to predict when the system architecture work might begin, let alone end.

Meanwhile, the Product Owner was waiting for some new functionality that he could use and show to his superiors—the stakeholders that he reported to in the business.  The program manager, who was the champion of the Scrum implementation, understood Scrum to be the way to succeed.  The first Scrum team was wrapping up on the first project in the new program and the business was happy with the process and the results.  This confirmed his understanding and gave him some traction to move forward.  But he didn’t have authority over all of the slated team members (specifically the sole developer trusted by IT management) to start.

I tried to explore possibilities of moving forward with the program manager.  The conversation went something like this:

TB: Are there some people who are available to start as the team for the new project?

PM: Yes.

TB: Great!  Do you need the star developer on this project or are there other people who have the skills to do the work who could be on the team?

PM: There are other people with skills who are available and who could be on the team.

TB: Great!  Do you have the authority to make that happen?

PM: Yes.

TB: Great!  Can we have the first Planning Meeting tomorrow?

PM: Yes.

TB: Great!  What time do we start?…

One might get the impression from reading that conversation that we were on our way to Sprint 1.  However, as we know, things are usually not that simple.  There were several more obstacles to work through.

(As an aside, I know that some people reading this might be thinking “what about Sprint Zero”.  These guys were talking about Sprint Zero, -1, -2…basically all the way back to Waterfall.  I needed to help them overcome that tendency.)

Below are a few of the other obstacles they were struggling with:

1. The program manager had assigned a project manager, one of his direct reports, as the ScrumMaster to the new Scrum team.  This person was already responsible for (and overwhelmed by) the Waterfall death march project now in perpetual change request mode.

Advice for anyone in this situation:

Find someone else to be the ScrumMaster.  It would be a better use of the external consultant (myself in this case) to serve as an interim ScrumMaster (coach) so that the team could just start, rather than trying to use a traditional project manager who was already overwhelmed by other responsibilities.  In other words, don’t wait for your ideal ScrumMaster candidate to be ready.  In most cases, management’s first choice for ScrumMaster is often not the best one.  If you do not have an experienced coach to serve as interim ScrumMaster, then the best thing to do is hire someone specifically for this role.  Again, it is better to just start than to wait for this new hire.  If you have to wait for the new hire, someone from the team should just volunteer and learn on the job until help arrives.  Even that will give you far better results than waiting.  Just start!

2.  The project manager who was assigned as the ScrumMaster was assigning Product Owner responsibilities to a business analyst that reported to him.  The “BA” was worried that the Product Backlog was not ready for the team.  The real Product Owner had created a high-level Backlog with items that were most likely too large for the team to complete within the two-week Sprint duration that they had decided on.  The BA was trying to work with the PO, but there wasn’t much reciprocity there, mainly because of lack of knowledge of the business on the part of the BA and the PO’s lack of trust in the BA’s ability to serve as his proxy on the team.  During one of my previous visits over a month before, the PO, BA and a few of the other team members had workshopped the Product Backlog, refining the top “epic” and creating a User Story small enough for the team to start working on and complete in the first Sprint.  Now, that story was lost and forgotten.

Advice for anyone in this situation:

Don’t wait for the Product Backlog to be perfect.  If the Backlog is not ready, use the first part of the planning meeting to identify what the team and the Product Owner can agree on as the deliverable for the first Sprint.  In fact, that is all you should be discussing in this meeting in any case.  With the right people in the room (the whole team) this can be done well enough.  If the team is not able to agree within the time box of this meeting, it most likely means that you don’t have the right people in the room.  For example, there may be a project manager and a BA who want to delay the start of the project because they feel uncomfortable with the perceived ambiguity of the process.  It would be better if these people were not on the team and not in the room.  If the team says something like “we can give you ‘X’ in two weeks” and the Product Owner says something like “good with me”, then make that your Goal for the Sprint and get on with the second part of planning—creating a set of tasks to execute the deliverable.

During the first Sprint, the Product Owner can be working with the team to refine the next items in the Backlog based on what has been learned from the Planning Meeting, which is probably a great deal.  The purpose of the Product Backlog is to realize a great Product.  Don’t wait for a perfect Backlog—just start!

3.  The culture of fear and distrust perpetuated by IT management was pervasive and the team was afraid to make a commitment to a deliverable.

Advice for anyone in this situation

Help people understand commitment as a team capability that develops over time.  Teams are able to make and keep commitments based on historical velocity.  For at least the first Sprint and perhaps for a while after that, new teams will not be able to make firm commitments.  Most teams fail to deliver after their first Sprint.  There is a learning curve to Scrum.  There is a lot of change and a lot of new things going on.  The environment of a new Scrum team is drastically more dynamic and complex than what most people have previously experienced.  It takes getting used to.  People need space to learn.  Help them overcome their fear of failure.  Agile is about failing fast.  Get it wrong early, learn, adapt and change course.  What a young team needs to be committed to is learning what it needs to do in order to deliver potentially shippable product every Sprint.  In order to do that, you need to be doing Scrum.

I started this post by identifying that there are many reasons to delay “doing” Agile. I believe this stems from a cultural dichotomy in our society between “being” and “doing”.  We don’t start doing something until we believe that we are prepared to succeed at it.  We have to “be” ready before we can “do”.  This is a false dichotomy that Agile is designed to help us overcome.  Another dichotomy is success vs. failure.  The only real failure in Agile is the failure to learn and improve.  Even the notion of “failure to deliver” is misguided.  The real failure is not learning to deliver.  In order to “be” Agile, you need to be able to fail.  In order to “fail” at Agile, you need to do it.  By doing Agile and failing, we learn to be Agile.  There is no other way.

So, please… just start!

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Building Capabilities for High-Performance, Part 1

This is my first crack at a series of posts intended to document reflections, insights and experiences that have been generated over the past several years at Berteig Consulting in our work helping organizations to transform with Agile methods and approaches.

The most recent iteration of our collective practice is the Real Agility Program.  The Program was created as a flexible yet systematic process for developing high-performance teams.  The Program involves assessments, training, leadership and delivery teams coaching and internal coach development for teams and organizations that want to transform in order to become hyper-productive, lean and robust.

A central tenet of the Program is that teams are organic in nature.  They are living systems that grow and develop in the right conditions.  They also develop in stages.  The Real Agility Program addresses the natural stages of team development with a sequence of steps or “sections”.

Much like a seed, a new team has the latent potential for developing into a complex organic system of high-performance capabilities.  Capabilities of high-performance start out as a simple set of attributes and grow in complexity and strength over time.  Capabilities to carry out more complex activities are built onto capabilities for more simple activities.  Little by little, high-performance can be realized in this way.

Something that most teams need help with early on, particularly if they do not already possess a growth mindset, is overcoming the false dichotomy between theory and practice.  An indication of this is when we hear people say things like “well, that makes perfect sense in theory, but it’s just not practical for us.”  Or “we need help to put that theoretical idea into practice in our own reality”.  This reveals a mindset that conversations around concepts and ideas are only valuable if they can be implemented immediately in a measurably beneficial way.  The desire for technical recipes is understandable.  They can help with immediate pain relief.  They are not the most effective way to build capabilities.

The Tree of Organic Growth is an exercise that we often share early in the Program and is designed to help teams develop a more integrated mindset and approach to capacity building (very similar to The Tree of High-Performance in Lyssa Adkin’s wonderful book Coaching Agile Teams).  The facilitator usually starts by drawing a simple diagram of a whole tree, including the roots.  Sometimes, simply exploring the concept in a conversation serves the purpose just as well.  The team is asked to identify values, concepts, principles, qualities, skills, attitudes, habits and knowledge that are already present on the team that will serve as roots for building capabilities of high performance.  The conversation is not merely a nice, (“fluffy”) theoretical stroll in the proverbial park, but a critical aspect of the hard work of re-shaping thought, which in turn re-shapes reality.

Let’s look at an example of the aspects of building a specific capability.  A well-known Agile capability of high-performance is the self-organization of the team.  On one level, it starts to happen as soon as a group of people come together to accomplish something and no one person is identified as the “boss”.  Without certain capabilities in the members, however, this can get very Animal Farm in almost no time.  High-performance requires the development of qualities, attitudes, conceptual knowledge & understanding, habits and skills in all members of the team.  For example, team members need to develop the qualities of openness, integrity and helpfulness.  Attitudes such as a humble posture of learning and serving the team need to be developed.  Knowledge of concepts such as consultative decision-making and Wideband  Delphi and how self-organization differs from traditional command and control project management needs to be developed.  Good habits and practices such as regularly coming together as a team to reflect and plan are essential for the team to become able to deliver complete increments of high value often.  And, of course, team members will need to learn skills in terms of communication and collaboration, as well as other technical skills that may have previously been outside of their formal roles.

Furthermore, everyone can develop in any of these areas of any capability at any given time.  Just like in any organic system, capabilities of high-performance benefit from constant nourishment, feedback and reinforcement.

Growing a high-performance team is a complex process that requires a great deal of effort, patience, time and a supportive organizational environment that will allow for all of these aspects to develop on a team.  It is an investment in people as much as it is a business decision.  There are no shortcuts or formulas, but with the right conditions, every team has the potential to develop capabilities of high-performance.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Reflections on Agile Business Leadership

From push system to pull system thinking

One of the disconnects holding teams back the most in an organization embarking on an Agile transformation is the lack of will and perhaps understanding of vision on the part of the business. The required shift in thinking is from a “push system” to a “pull system”. Historically and still culturally, most organizations, even those claiming to be ‘Agile’ are very much push systems. The business folks in client services – VPs, Directors, sales people, etc. seem to make time (deadline) commitments to clients on behalf of teams and then the teams are given the deadlines to finish the work. Sometimes, the deadlines are decided on in consultation with particular individuals on the teams and very rarely, if ever, with the actual teams themselves. In any case, the fact that the business is almost entirely deadline-driven is the centre of the push system. Deadlines push or drive everything else. Deadlines are fixed and often considered non-negotiable. Deadlines are a taboo subject – it is considered a waste of time to even discuss them because they just don’t and won’t ever move. The general attitude is that if we try to move deadlines, we put the entire business at risk because our clients will drop us and turn to one of our competitors who claim to be able to promise and keep deadlines. If we lose our clients, we lose business, we lose money and it potentially puts us all out of jobs. What this exposes is not only a push system driven by deadlines, but a culture that is actually driven by fear. The not-so-implicit message is that if you miss a deadline, you might lose your job, so you had better do whatever it takes to not miss the deadline. Or else. Push and pull systems and mentalities are like oil and water – they don’t mix. In Agile, there is no place for fear of failure. Rather, teams must be allowed to fail (miss deadlines) and learn from their failures (plan better).

Why quality, not time/cost or scope is non-negotiable

The “make the deadline or else message” is couched and clouded by other talk. The main excuse is to blame the client, as noted above. “That’s just the way our clients work, the way the market works”. Of course, such an excuse contains a kernel of truth. Without a true understanding and embrace of Agile, the idea of not meeting deadlines and the perceived consequences can be truly scary. Generally, there is an understanding from the business that the productivity of teams may drop somewhat as they progress through the storming stage. What this translates into is a difficult discussion with clients around delayed delivery. It is tolerable in that it is temporary. “Once the teams get up and running, we can go back to meeting our deadlines, and even be able to deliver early because Agile is supposed to be faster.” But the benefits of truly adopting Agile are much more powerful than this.

Understanding the true business value of Agile

What needs to be understood is the true business value for investing in Agile processes and practices – how it may add cost and time to the initial development Cycle, but how it saves both the business and the client tremendously on technical debt and support long-term. This needs to be understood and championed by the business in order for the organization to become liberated from its enslavement to the push system mentality. At the heart of such a mental liberation is the wholehearted adoption and commitment to the Agile/Lean principle that quality is non-negotiable. The investment in Agile processes and practices is essentially an investment not only in quality, but in continuous quality improvements towards the goal of being able to frequently deliver products of increasing relevance and quality (value). The ability to ship frequently allows for sustainable growth. All of this is made impossible by the deadline-driven push system mentality/culture of fear.

The urgent need for slack

One of the first things that a team needs in order to focus on continuous quality improvements is slack so that it can learn to learn. The first goal of the business leadership should be to facilitate scope and deadline slack for the team. This goal should also be fully and visibly championed by the business leadership. In order to develop the capability to facilitate slack, the business needs to gain knowledge around the purpose and importance of Agile processes and practices and be able to articulate a strong business case for them. The business leadership needs to develop the skill of educating the team, management and business leadership on the long-term benefits of an Agile transformation – the transformation from a push system to a pull system. The key stakeholders and business leaderships need to possess the courage to engage in difficult conversations with management and clients who may be upset by the short-term pain of delays and missed deadlines and protect the team from continued attempts to push work into the team. Perhaps above all, the business leadership needs to develop an attitude of learning – a humble learning posture that allows for the setting aside of preconceived notions, fears and prejudices around what it means to be a good business leader. A leader possessed of this posture demonstrates a learning attitude by stressing first and foremost the importance of creating slack for the team to learn to learn. It is a common pitfall for inexperienced business leaderships and stakeholders to expect Agile to provide solutions for their push system woes, woes that include the broken trust of clients from consistently broken (unrealistic, dreamt-up) deadline promises and the crippling effects of technical debt (the fallout of the former – when scope, time and cost are fixed, quality is compromised).

If the business leadership, with the support of the Process Facilitators and the Transformation Team, is able to foster the organizational will to create slack for the teams, then the teams will have the space they need to truly focus on continuous quality improvements. This is a critical milestone on the path to realizing the true, measurable benefits of Agile. Although the support of others is needed, the business leadership is in a unique position benefitting from an intimate relationship with both the needs of the business as well as the daily life of the team.

Why the business leadership needs to own the process

The first way that the business leadership creates slack for the teams is by championing the process. In OpenAgile, like all other Agile methodologies, there are key features of the process the purpose of which are to give space for new teams to begin to make the often seemingly inconsequential, yet ultimately critical first steps towards continuous quality improvements. One of the most obvious of these features is the Agile team meetings. In the early stages of team development, organizational understanding and will, the OpenAgile meetings (particularly the Reflection and Learning aspects of the Engagement Meetings in OpenAgile) can easily be discounted as an obstacle preventing the team from getting the “real work” done. What is often forgotten under the pressure of deadlines is the fact that in order for a team to be able to learn to make continuous quality improvements, it needs to develop the capability of systematic (frequent & regular) inspection and adaptation of the way that it works. It is easy to save on the short term pain of perceived non-negotiable deadlines (meeting deadlines at all cost = success) by compromising on investing in the process, especially when the team is still learning to learn and the effectiveness of the meetings is not yet apparent. When the team and the organization have an expectation of Agile as something that fits into the push system and allows for a team to function better within such a system, it can be hard to understand how spending time in a kind of meeting that the team doesn’t seem good at yet can be of any value. This is where the business leadership needs to stand firmly behind the process. The team needs the meetings – the space to reflect, learn and plan – in order to learn to become more effective at making continuous quality improvements – a critical feature of an effective pull system. Without the meetings, the team will never develop this critical capability and as a result, will never become an Agile team. Instead, the team will revert back to getting the “real work” done with all of the quality problems crippling the organization and which led to the decision to adopt an Agile framework in the first place.

Why the business leadership should care about burn-down

Another key feature of the process for the business leadership to understand and champion is the concept of burn-down as represented by the burn-down chart of an Agile team. Agile doesn’t care about how much work the team gets done. It assumes that the team is doing valuable work and getting things done – in other words, that the team is managing itself and working towards its goals and commitments. There are no tools in Agile for an individual, least of all the business leadership, to measure and manage how much work the team is getting done. Agile acknowledges the reality that real (sustainable) productivity cannot be forced on any team. Instead, a team grows its productivity at a sustainable pace when it is given enough slack to do so. The team makes a plan at the beginning of the Cycle based on what it understands about its capacity, works towards that goal throughout the Cycle and hopefully delivers valuable results at the end of the Cycle. By learning to apply the process of continuous improvement, quality and productivity go up hand in hand. That is the essence of the pull model. Through all of this, the team manages “how” it gets work done. The productivity of a team can be measured, but the burn-down chart is neither an appropriate nor effective tool for measuring the productivity of a team. Instead, burn-down provides one specific measurement and ONLY this one measurement: WORK REMAINING (in order to achieve the goal/commitment of the current Cycle). It does not and cannot tell you how much the team got done and even less so the whys and hows of the output and productivity of the team during the Cycle.

So what is the purpose of burn-down and why should the business leadership even care? If it can’t be used as a tool to measure the productivity of the team (in other words, if it can’t be used to manage the team) then what importance can it possibly have? These are typical questions of teams and individuals that are coming from a traditional project management, i.e. command & control, i.e. “push” system mentality. Understanding the purpose of burn-down depends on the ability to make the shift from the push system paradigm to the pull system paradigm. In a push system, burn-down is nice but somewhat irrelevant. For an organization committed to an Agile transformation (towards a pull system of self-managed teams) it is an invaluable launch pad for powerful conversations that live at the heart of continuous quality improvements.

Commitment to the business requirements come from the Agile teams

When a team decides on a plan for a Cycle of work, the plan is a commitment. This is a critical step in the Agile process. It is only after a unanimous commitment from the whole team that the team begins to work on the plan. If any individual team member feels hesitant about the work in the plan, tasks and potentially even Value Drivers should be removed until everyone is comfortable making a commitment. When the business leadership is telling a team what the plan is, then it is not the team’s plan and therefore it cannot be a team commitment. This is not only an inappropriate use of authority, it is also breaking the Agile process. Moreover, when a plan and therefore a commitment is forced onto a team, the team cannot be held accountable for failure. Worse yet, the team will never learn to plan. If a team is not able to plan, then it is not able to make commitments. If the team is overwhelmed by an overly-ambitious, management-forced plan, it will not learn to evaluate its capacity and apply that knowledge to long-term planning and project estimates. It will not learn to make meaningful quality improvements and reflect on its progress. It will not learn to self-manage or self-organize. The purpose of burn-down is to establish commitment velocity. In other words, the amount of work that the team can truthfully expect to complete during the Cycle when it is making the Plan. The difference between the number of tasks in the Cycle Plan and the number of tasks remaining at the end of the Cycle gives the team its commitment velocity. Commitment velocity is always based on minimum historical velocity. The team uses commitment velocity to make a Cycle Plan containing no more than the number of tasks represented by its commitment velocity. This allows the team to spend just the right amount of effort and time on planning and allows the team slack to focus on the truly Agile work of learning and continuous quality and process improvements. Over-planning, especially when it is wedded to over-committing or even worse, non-committing (a common push system mentality pitfall forced onto teams by the business leadership) leaves the team in a state of dependent on daily micro-management and can completely halt the progress of a team. Not to mention that this is a flagrant violation of Agile values (truthfulness, responding to change over following a plan) and principles (sustainable development). Such compromises to foundational Agile values, principles and processes may produce desired results in the very short-term, but the long-term costs can be crippling to teams and organizations. The wasteful activity associated with team dependency on micro-management is what often leads organizations to the accumulation of technical debt that places them in dire competitive disadvantage and desperate need for Agile transformation in the first place. If an organization misses out on this golden opportunity, teams can become demoralized and innocuous to the Agile practices and the promise of an Agile transformation can quickly erode.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Coaching Agile Teams class – Toronto, Canada – June 17 & 18, 2013

 

Coaching Agile Teams  course descriptionCoaching Agile Teams is a training experience that covers both the being and the doing of agile coaching.  There’s a lot to learn, experience and practice! At the end of the course, you will be capable of applying many new tools and techniques, as well as your own mindset changes, to coach agile teams to high performance. As practical as it is provocative, the Coaching Agile Teams course challenges agile coaches to rise to the fullest expression of their role and offer simple, practical ways to get there.

 

Outcome
You’ll walk away from the course with your personal coaching improvement backlog – a tangible plan you can use to thoughtfully improve your coaching when you’re back in your daily circumstances.  We use your real world situations and scenarios throughout the class allowing you to craft powerful ways to address the challenges you face.  You’ll also have many new things to try with your teams and you will probably depart with a few provocative ideas to chew on (in fact, maybe wrangle with for a while). All of these outcomes add up to your ability to become the excellent agile coach your teams need. 

Register for Coaching Teams Class here!
http://www.eventbrite.com/event/6102981181?discount=Berteig_promo

 

 

 

 

 

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

OpenAgile London 2013 – March 18th – UWO!!!

OpenAgile London 2013 is the first annual conference focused on OpenAgile and how it is used in organizations by real teams. London was chosen due to the great learning environment with both the University of Western Ontario and Fanshawe College being located here. This conference is meant to help both students and professionals by providing learning and networking opportunities.
The purpose of OpenAgile is to create an environment in which people are free to express their true nature and capacities to contribute to the betterment of their organization.
We welcome you to participate in this informative and inspirational event that will give you the tools for the future of management!
For Registration and more info visit visit http://www.openagilelondon.com/index.html

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: OpenAgile Conference!

Hi Everyone,

I’m pleased to announce that a mini-conference for OpenAgile, with some great speakers, has been planned and is ready to accept early-bird registrations!  The conference takes place in London, Ontario (yes, there is an airport) at the University of Western Ontario on March 18th.

Check out the conference information at http://www.openagilelondon.com/

I will be one of the speakers, along with some great industry leaders!  I look forward to seeing some of you there!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Why we SCRUM: Achieving Hyper-productivity. Presented by Myplanet Digital and Berteig Consulting

On Friday, October 28th at 1pm join Paul Heidema from Berteig Consulting and Shanly Suepaul from Myplanet Digital as we discuss what Scrum is, how we use it at Myplanet Digital and how Scrum can help your team.
 
Scrum is the lifeblood of Myplanet. When executed properly it empowers teams and individuals to stay motivated and achieve excellence. Most importantly, Scrum allows us to continually learn and improve our people and teams.
At Berteig Consulting, we are experts at using agile methods such as Scrum to transform people, process and culture in order to produce high-performance teams and organizations. From ScrumAlliance.org: “Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless.”

Sign up here: https://eval.webex.com/eval/onstage/g.php?t=a&d=924723906 


Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Outside of Software

The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:

1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan

I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.

On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.

Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

How to Introduce a Test Driven Mindset

Recently, I was helping a friend of mine introduce OpenAgile into their environment. They are a software development house with some local and some overseas developers. I am occasionally following up with my friend to see how they are doing.

Their development has been going well since adopting Agile practices with the exception of a recurring problem with “returning bugs”.

A bug will be discovered, fixed, and then several weeks later will show up again after some other modifications.  This is a sure sign that Test Driven Development is not happening.

Consider the following:

  • There is a master data entry screen called “Shipment Entry”.  The first field on the form has a “Shipper” field that allows the entry of a Shipper Code.
  • If you press CTRL-N, you Should get a sorted list of Company Names ordered by CompanyName, paged 20 at a time, with a smaller selection if some of the characters of the company name have been filled out.  The resulting list should appear within 3 seconds.
  • Today you downloaded the code, recompiled and find that the drop down does not sort anymore.
  • You know that you have fixed this before.

Introduce the Test Driven Development Mindset.

Instead of opening a ticket, sending an email, complaining or whatever your process is, consider trying the following and introducing something like this into your source / version control.
Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.

If any developer works on that screen, before checking in, they need to do all the tests on the SHIPMENT ENTRY TESTS document to ensure they have not broken anything.Don’t get me wrong. The idea is not to document the entire screen up front! Try to avoid designing the ENTIRE UI up front in this way. That has it’s own non-agile problems. This is just an easy way to introduce future changes using a different mindset.In my example above, there is a field called “Mode of Transport”. It currently shows a list of numbers which internal employees “KNOW” from years of experience with the application. When that number is selected, it gets converted into something like “MAIL”, “COURIER”, when it is printed on the final document. Your team has agreed to do work to have it show the appropriate labels in a drop down on the screen.Traditionally (non-test mindset), you would send out an email or open up an issue with a request for this change. Then, the cycle will continue again. As time goes by, you will always need to re-check this is working properly.

Try something like this instead:

When you have finished your planning and have decided this “story” or “feature” will be introduced to this cycle or Sprint, simply modify this document as follows;

Shipment Entry Screen Tests
Shipper Field is Empty, CTRL-N pressed List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has “ABC”, CTRL-N pressed List Appears (filtered to show all companies containing “ABC” in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper Field has an invalid entry “INVALID”, CTRL-N pressed Within 3 seconds, a pop-up appears indicating “NO COMPANY FOUND”, the shipper field is blanked and the cursor is returned to that location. The popup disappears.
Mode of Transport Entry into Field Within 1 second, when entering this field, a drop-down list appears show full descriptions, sorted alphabetically by Mode of Transport.

Granted, the tests will eventually become cumbersome. However, please remember that someone will eventually be testing these screens and find these bugs in a never ending circle. My friend found that every morning they were having to go through all the screens to see what “new things” were broken.

Why not just try to get it right during your Cycle or Sprint ?

In the above example, as soon as someone takes on this task, they will have a failing test (Red), they will do what they need to do to get the test to pass (Green), and then will adjust the code to be efficient (Re-factor).

Although Test Driven Development is better done at other places in the code, this is a great way to introduce the “Mindset” into your team.

Someone will eventually say “This is getting to be a hassle. Can we automate it somehow?”, which as an Agile person is exactly the words you eventually want to hear.

Maybe now, you can start to introduce it at the Unit Test, or Functional Test or whatever level is appropriate to your organization. There are some more formal ways of doing TDD such as Extreme Programming (XP).

The important thing is that your company will have shifted to a Test Driven Mindset.

The quality of your product will increase and stay that way and the need to go back and fix old bugs in a never ending cycle can soon be a thing of the past.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

What if your first cycle ends up with zero story points completed?

I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps.  We focused specifically on OpenAgile.

They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer… NO.

The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to “see how they felt” about learning about OpenAgile.

There were no commitments made to it. The idea of “Hey, let’s learn about this and see if it’s right for our organization” was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn’t feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor.  The fact they felt they could do this shows true management leadership and support for the process.

I have to congratulate my friend for his courage in supporting his team.

The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction “around the edges” of the Agile team.

We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion.  Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

The team was actively taking steps to improve the next cycle.

If senior managers encourage the right environment and let the team self-organize… you know what.. they likely will :->

Things that went poorly

  • Two days into the cycle, some of their overseas developers went “to visit family”. They did not realize at the time, this was local code for “going on holidays”. I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.
  • The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.
  • Attempts at Test Driven Development did not go well.
  • The first two week cycle stretched to 3 weeks because the team didn’t want to have Zero velocity as they felt this was a failure
  • One display bug crept into the first demo related to two different ways of refreshing data on the screen

Things that went well

  • The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle.  This is also how they found out about the missing developers.
  • The owners and managers had an active involvement in helping to remove obstacles.
  • The team found an intriguing way to determine how many story points they could actually commit to in future cycles.
  • The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.
  • The team stayed together and focused on the goal of creating potentially deliverable product
  • They were able to successfully work on two simultaneous streams of work on different parts of the system.
  • During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.

Summary

I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen.  This can be compounded by added complexities of your working environment or project.

Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

They simply took on too much work, didn’t account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

One of the great things to come out of their first cycle…. A potentially deliverable product within the first two cycles!

When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small.  Consider it of huge Value to the Agile process.

You need to provide some positive feedback for the team members now.  This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

They are looking forward to shipping their new product in record time :->

One comment that was made to me was something along the lines of “Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That’s what made us successful in the first place.”…. Hmmmm.

Mike Caspar, CSM, OA2/5

References: OpenAgile - www.openagile.com

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Agile Tour Toronto November 3

This is just a quick post to share that Agile Tour Toronto is coming soon. It is on November 3 in Toronto. It will be a great day with plenty to do, much to learn, and so many people to meet.

We will be there too. Berteig Consulting has a booth and many of us will be there to meet all of you. Hope to see you there!

Here is the link: http://www.torontoagilecommunity.org/att2011

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail