Category Archives: Theory of Agile

David Sabine: What Real Agility Means To Me

Learn more about transforming people, process and culture with the Real Agility Program

Image

“Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future,” David Sabine

My name is David Sabine. I’m a Real Agility Coach and have been thinking about what Real Agility means to me.

My introduction to Real Agility began in 2007 when the CTO of the college I was working at in Fort McMurray, Alberta brought in Mishkin Berteig as a third party consultant. Back then, I was a software developer and what I experienced then is still true today. The value of bringing in a third party to solve business challenges is immeasurable.

Time and time again, as I have been involved with companies, either in a training or a consulting capacity, I have found that a third party presence provides or creates a break-through. The purpose is not that I go to a company as a consultant and I bring my new ideas, as though I am the only one with new ideas.  What happens instead is that I visit a company and my presence, as a coach, opens the door for the internal staff to explore their own new thoughts, or concepts or possible solutions. So the ideas that are already in the company are just allowed to blossom a little bit in the presence of a third party,because this third party allows or creates a sense of permission, a sense of autonomy for those staff. They’ve been invited to explore concepts and they’ve been invited to think through their business problems from a different perspective and I am there just to reflect what they already have or what they already know.

That occurred when Mishkin Berteig visited the college in 2007, and that occurs every time I go and visit a company for training or consulting.

To really understand what Real Agility means to me, I’d like to tell you about how I came to software development in the first place beginning back in 1993 when I was starting university and was a freelance musician.

I had two passions at the time: the pursuit of music and the logic of programming. My computer tended to pay the bills, more so than being a freelance musician, so as a career path I guess I was drawn to software development and started to build my own products early on in 1996-1997. I was writing software for small business clients with the aim to eventually build a product on my own and release it for sale worldwide.

In 2000, I started to develop a product with a friend of mine. In 2001 we released it to other developers in the world. Our first sale of that product was in Belgium and for the next few years it sold worldwide. We had about 2000 websites that were using our product and it was translated into seven different languages by the community of users. It provided my friend and I with a reasonable income and a great opportunity. It was fun!

In 2006, I realized that my own growth as a computer scientist required working with others beyond this friend, to work in a team, in fact. I moved to Northern Alberta and worked in IT department for a college. As I mentioned, in 2007, the CTO, brought in Mishkin Berteig to provide us with a 3-day training course on Scrum. Quite immediately I loved it because I could see how it would provide us with a lot of opportunity to solve problems we were facing in an IT department and, secondly, it just seemed like a more human way to work. I was reflecting on all of these periods I had had as a musician, working with other musicians, and it just seemed like a better way to approach the creative endeavor than other project management methods that were in play at the time.

Since that time, I’ve been practicing them in a variety of settings and I’m more convinced now than ever that the Agile Manifesto provides us with a great solution space as we respond to business challenges. Recently I’ve decided not to be a developer or product owner but have decided to join Berteig full time and train and coach other teams.

So that’s the story of my personal evolution. My personal journey.

Looking back on that training I can see how I felt immediately that Real Agility was an alternative way of doing things.

I studied music since I was a child and music has always been a huge part of my life,and as a musician, one becomes aware of or familiar with continuous improvement. This is the same concept found in Real Agility. But with music it’s incremental, tiny, tiny increments of improvement over time. We respond to an audience. We respond in real time to our fellow musicians. We are always taking in input and that informs our performance of the music. As musicians, we spend a lot of personal time developing our craft. We spend significant time in performance so we can receive the audience feedback.

What I mean to say is that musicians are excellent examples of high performance teams and are excellent examples of creative excellence, who understand tactical excellence and what it means to get there.

When I joined Software development in a large, bureaucratic institution – the college – it was anything but natural for me. At that time, I was more than just a software developer. I was systems analyst, database admin and a variety of positions or roles. It just felt like an industrialized, mechanical environment where people were expected to behave as interchangeable units of skill. Work was expected to get done in the prescribed procedure. And decisions were expected only to be made by the smartest or the highest paid few and if you weren’t of that ilk, you were not expected to behave autonomously. You were expected to be just part of the machine and it felt very inhuman, as most people feel as a part of a large hierarchical bureaucracy.

When Mishkin facilitated the Certified Scrum Master training course in 2007, it just blew all those doors open. It reminded me that we can approach our work the way I had naturally approached it, as a creative individual who is capable of learning and wants to receive immediate feedback from audience or user, and who can make autonomous decisions about how to apply that feedback into the continuous development of software and systems and large infrastructure.

These business challenges are pretty common. They are delayed projects or projects that that blow the budget, or where a group of people are assigned to the project and they can’t possibly complete the scope of work in the time given. Or staff are demoralized, and how that expands through enterprises. There are many examples. The college where I was working suffered all of the most common issues and the one that hurt me the most or I felt the most was attrition. Dis-engaged staff. The reason for it was simple. The college had not presented with them a purpose or opportunity to be masterful. The extrinsic motivators, salaries and such, were just enough to keep people for a little while and then they would leave. And so the college at the time was experiencing attrition of 35-40% per year and that’s what I meant by inhuman.

“These Real Agility methods presented a change. In fact, people become centric to the purpose!”

When I read the Agile Manifesto I think that it provides us with solutions, and so if our current business problem or business circumstance is that we have disengaged staff who aren’t very productive and aren’t getting along well, then the Agile Manifesto reminds us that perhaps business people and developers can work daily throughout the project together. They can have continual interaction, and then individuals and their interactions become more valuable than the process and the organizational tools that have been put in their way. It reminds us that people should be allowed to work at a sustainable pace. We should build projects around motivated individuals. And that poses questions about how to do those things. What does it mean to be motivated, and how do we build projects around motivated people?

So Agile Manifesto presents us with some challenges, as a mental process, and then when we work through that we understand how it can inform good decisions about how to solve business problems.

Real Agility to me means being aware of and accepting of the present, in order to respond and chart new courses for the future.”

In other words, Agility means being nimble, the ability to adapt to current circumstance, but more than that, Real Agility means that we should approach our work with the intention that we stay light-weight so that when our circumstances change we can adapt without a lot of inertial resistance. So there’s two components there. One is being able to adapt quickly, and being aware of present circumstance but the other is that we don’t want to take on weight and institutional mass, because that’s inertia, the status quo.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Sabine’s Principle of Cumulative Quality Advantage

Learn more about transforming people, process and culture with the Real Agility Program

Many organizations won’t survive the next decade. Of those that survive, even they are likely to be extinct before century’s end — especially the largest of contemporary organizations.

I was thinking today of a few essential adaptations that enterprises must make immediately in order to stave off their own almost-inevitable death.

With Regard to Business Strategy

  • Measure value delivered and make decisions empirically based on those data.
  • Strive toward a single profit-and-loss statement. Understand which value streams contribute to profit, yes, but minimize fine-grained inspection of cost.
  • Direct-to-consumer, small-batch delivery is winning. It will continue to win.

With Regard to People

  • Heed Conway’s Law. Understand that patterns of communication between workers directly effect the design and structure of their results. Organize staff flexibly and in a way which resembles future states or ‘desired next-states’ so those people produce the future or desired next-architectures. This implies that functional business units and structures based on shared services must be disassembled; instead, organize people around products and then finance the work as long-term initiatives instead of finite projects.
  • Distribute all decision-making to people closest to the market and assess their effectiveness by their results; ensure they interact directly with end users and measure (primarily) trailing indicators of value delivered. Influence decision-making with guiding principles, not policies.
  • The words ‘manager’ and ‘management’ are derogatory terms and not to be used anymore.
  • Teams are the performance unit, not individuals. Get over it.

With Regard to Technology

  • Technical excellence must be known by all to be the enabler of agility.
  • Technical excellence cannot be purchased — it is an aspect of organizational culture.

For example, in the realm of software delivery, extremely high levels of quality are found in organizations with the shortest median times-to-market and the most code deployments per minute. The topic of Continuous Delivery is so important currently because reports show a direct correlation between (a) the frequency of deployment and (b) quality.

That is, as teams learn to deploy more frequently, their time-to-market (lead time), recovery rates, and success rates all change for the better — dramatically!

I have a theory which is exemplified in the following graph.

Sabine’s Principle of Cumulative Quality Advantage Explained

As the intervals between deployments decrease (blue/descending line)

…quality increases (gold/ascending line)

…and the amount & cost of technical debt decreases (red area)

…and competitive advantage accumulates (green area).

Note: The cusp between red and green area represents the turning point an organization makes from responding to defects to preventing them.


This is a repost from David’s original article at tumblr.davesabine.com.

This post is inspired in part by these awesome texts:


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

VIDEO: What is all the buzz about agile?

Learn more about transforming people, process and culture with the Real Agility Program

This short clip gives a great overview of where the idea of being agile came from, how it was used in software development first, and how it’s being used now.

“Remember: Agile’s success comes from working differently. Not from working faster.”


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Youtube Video: Paradigm Shift by Mishkin Berteig

Learn more about transforming people, process and culture with the Real Agility Program

Many organizations are attempting to use Agile methods.  Banks, telecom companies, government agencies, and all manner of mid-size and small organizations.  Most of these attempts are limited in that they think of Agile as a solution instead of as a culture.  In this video, I explore the paradigm shift which is needed for long-lasting change.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

“Teams” Larger Than Eleven Are Not Scrum Teams

Learn more about transforming people, process and culture with the Real Agility Program

Mobbing Team

Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.

Considerations for re-organizing into multiple Scrum Teams:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Face-to-Face Value

Learn more about transforming people, process and culture with the Real Agility Program

Linkedin has introduced a new app called Linkedin Lookup, advertised as “the fastest way to find and learn about your coworkers.”

If you don’t know who your co-workers are then your Enterprise has big problems, and a LinkedIn app won’t solve them. But Agile can…

The first Value in the Agile Manifesto reads: “Individuals and interactions over processes and tools.”

What does that mean? For some understanding, you might read this excerpt from: Applying Agile Management Value 1: (Agile Project Management For Dummies)

The first core value of the Agile Manifesto is to value individuals and interactions over processes and tools. When you allow each person to contribute unique value to your software development project, the result can be powerful.

… This emphasis on individuals and teams puts the focus on people and their energy, innovation, and ability to solve problems. You use processes and tools in agile project management, but they’re intentionally streamlined and directly support product creation. The more robust a process or tool, the more you spend on its care and feeding and the more you defer to it. With people front and center, however, the result is a leap in productivity. An agile environment is human-centric and participatory and can be readily adapted to new ideas and innovations.
If you do not know who your employees or co-workers are, if you are never with them when they are engaging in their work to note their individual styles and capacities, then you are part of the old corporate way of conducting business, and will not be able to succeed given the current needs that demand a more humanistic approach to problem-solving and increased production – in other words, needs that demand agility.

What does it take to introduce yourself to a co-worker on another floor? What does it take to encourage an individual or team struggling with a creative problem? What does it take to tell someone, face-to-face, their work is well done?

These small interactions can have a great effect on any individual. She/he will feel valued, needed, noticed, regarded, and will likely want to learn and work even harder to increase his/her potential.

In Forbes magazine, January 2015, Steve Denning wrote an interesting article that speaks to the value of “individuals and interactions over processes and tools. His piece is called ”Why do Managers Hate Agile?”

http://www.forbes.com/sites/stevedenning/2015/01/26/why-do-managers-hate-agile/
In it, he compares the vertical mindset and approach of corporations, which served them well one hundred and fifty years ago, to the horizontal approach that Agile offered in the late part of the 20th century as a response to changing needs in the world.

Denning writes:

Agile, Scrum and Lean arose as a deliberate response to the problems of hierarchical bureaucracy that is still pervasive in organizations today: falling rates of return on assets and on invested capital, a dispirited workforce and widespread disruption of existing business models.

…the world changed and the marketplace became turbulent. There were a number of factors: globalization, deregulation, and new technology, particularly the Internet. Power in the marketplace shifted from seller to buyer; average performance wasn’t good enough. Continuous innovation became a requirement; in a world that required continuous innovation, a dispirited workforce was a serious productivity problem. As the market shifted in ways that were difficult to predict, static plans became liabilities; the inability to adapt led to “big bang disruption.” In this turbulent context, the strengths of hierarchical bureaucracy evaporated. In this context, businesses and institutions requires continuous innovation.”

Social media apps can be fun and helpful, but they cannot replace human face-to-face interaction. Think about Agile’s first value as a place to begin.

 

 

 

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Article Review: Thinking About the Agile Manifesto

Learn more about transforming people, process and culture with the Real Agility Program

Often times, as I’ve been researching about agile methods and how to apply these to create real and sustainable change in an organization, I come across reference to the Agile Manifesto. I list it here today for those who are new to the field or who are getting back to the roots after trying a few things with different-than-expected results. It is an instrumental document. The values and principles listed here truly do shape the way agilists think and operate and to some degree or another the results appear to be better than before this founding document was introduced. So here is my “hats off” to this remarkable item which plays a pivotal role in cultural transformation.

The four key values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Personally, I find the first one the most meaningful of all. When we value individuals and interactions over process and tools we are truly improving in leaps and bounds in creating collaborative environments which are continuously improving.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What You Need To Know About Disruption

Learn more about transforming people, process and culture with the Real Agility Program

This information was presented by John Hagel in a Scrum Alliance webinar, April 12, 2016. These are my notes plus a few thoughts.DSC_0616.

The idea of Disruption in business was popularized in ‘97 in a book by Clayton Christensen. What is disruption? It occurs when most of the leading incumbents (in business, politics, technology, etc) are displaced by a new approach that is challenging to replicate. Disruption can usually be quickly seen in a change in economic factors or a change in mindsets.

There are 5 aspects of disruption to be aware of:

1. it’s happening across every industry

2. well-managed firms don’t make you safe from disruption

3. most firms/ businesses did not see it coming, i.e. newspaper industry

4. disrupting companies are not themselves immune from disruption

5. there are multiple-patterns or inter-related patterns of disruption

Most companies focus on their high-value estimates; their low-value customers don’t seem to be a threat. But as low-value items or services steadily improve, we see high-value customers shift to that. Firms must become Agile and be able to adjust on-the-fly to new technologies; they should not focus on adding improvement just to high-value things.

John Hagel clarified that disruption is a universal phenomenon – “the story of the century.” Many companies are not weathering the storm. The average life of a leading company in the ‘50’s was 62 years – now it is 18 years.

This is due to a fundamental shift in value creation, whereby consumers are gaining more power with more information and options, and knowledge workers are gaining more power in that talent has greater visibility, and higher wages can be continually demanded.

Hagel’s research shows that there are patterns that can act as lenses through which disruption can be viewed. The first pattern relates to the transformation of value and economics. For example, the digital camera became a huge disruption to the photography industry, but now itself has been disrupted by the ability to embed digital cameras in cellphones. The second pattern relates to “harnessing network effects;” the more participants that join, the more value is created. This pattern is more enduring and challenging to disrupt.

In your industry, what would you look for to understand market vulnerability? Would it be through product pricing, product modularity, demand characteristics, or supply constraints? If you assess your industry, which catalysts are the most important to understand to deal with disruption?

My personal thought is that, given the organic nature of the world’s systems, whatever disruptions are trending in the world around us, sooner or later they will have an effect on most businesses and organizations.

Disaster can be staved off by becoming more Agile in your organization. Agile will help everyone respond more quickly and with flexibility to disruptions. In fact, Agile itself has become a disruptive factor for outmoded ways of doing business.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Refactoring: 4 Key Principles

Learn more about transforming people, process and culture with the Real Agility Program

I believe in refactoring.  The Agile Manifesto holds that

The best architectures, requirements and designs emerge from self-organizing teams.

The quality of our software systems depends on refactoring.  In fact, I believe that the only way that an organization can avoid refactoring is by going out of business.  Maybe I should explain that.

Refactor or Die

Heart Monitor Flatline - Refactoring or DeathEvery software system that we build is inside a dynamic environment.  The organization(s) using the software are all in a state of constant change.  The people using the software are also constantly changing.  Due to this constant change, every software system needs to be adapted to the environment in which it is used.  Most of the time, businesses think of this constant change in terms of new features and enhancements – the scope of functionality that a system can handle.  Less commonly, businesses think of this change in terms of the obvious external qualities and attributes of the system such as performance or security.  But almost never does an organization, from a business perspective, think of the invisible qualities of the software system such as simplicity and technical excellence.

What happens when the business does not recognize those invisible qualities?  I’m sure almost every software developer reading this can answer this question easily: the system becomes “crufty”, hard to maintain, bug-prone, costly to change, maze-like, complex.  Some people refer to this as legacy code or technical debt.

The longer this state is allowed to continue, the more it costs to add new features – the stuff that the business really cares about.  It is pretty easy to see how this works – for someone who has a technical background.  But for those without a technical background it can be hard to understand.  Here is a little analogy to help out.

Imagine that you set up a system for giving allowance to your kids.  In this system, every week your kids have to fill out a simple form that has their name, the amount that they are requesting, and their signature.  After a few weeks of doing this, you realize that it would be helpful to have the date on the form.  You do this so that you can enter their allowance payments in your personal bookkeeping records.  Then you decide that you need to add a spot for you to counter-sign so that the paper becomes a legal record of the allowance payment.  Then your kids want extra allowance for a special outing.  So you add some things on the form to allow them to make these special requests.  Your accountant tells you that some portions of your kids allowance might be good to track for tax purposes.  So, the form gets expanded to have fields for the several different possible uses that are beneficial to your taxes.  Your form is getting quite complex by this point.  Your kids start making other requests like to be paid by cheque or direct-deposit instead of in cash or to be paid advances against future allowances.  Every new situation adds complexity to the form.  The form expands over multiple pages.  Filling out the form weekly starts to take significant time for each child and for you to review them.  You realize that in numerous places on the form it would be more efficient to ask for information in a different way, but you’re not sure if it will have tax implications, so you decide not to make the changes… yet.  You decide you need your own checklist to make sure that the forms are being filled out correctly.  A new tax law means that you could claim some refunds if you have some additional information… and it can be applied retroactively, so you ask your kids to help transcribe all the old versions of the form into the latest version.  It takes three days, and there is lots of guess-work.  Your allowance tracking forms have become a bureaucratic nightmare.

The forms and their handling is what software developers have to deal with on a daily basis – and the business usually doesn’t give time to do that simplification step.  The difference is that in software development there are tools, techniques and skills that allow your developers to maintain a system so that it doesn’t get into that nightmare state.

For a more in-deth description of this process of systems gradually becoming more and more difficult to improve, please see these two excellent articles by Kane Mar:

Technical Debt and Design Death

Technical Debt and Design Death: Part II

Ultimately, a software system can become so crufty that it costs more to add features than the business benefit of adding those features.  If the business has the capacity, it is usually at this point that the business makes a hard decision: let’s re-write the system from scratch.

I used the word “decision” in that last sentence.  What are the other options in that decision?  Ignoring the problem might be okay for a while longer: if the company is still getting benefit from the operation of the system, then this can go on for quite a while.  Throwing more bodies at the system can seem to help for a bit, but there are rapidly diminishing returns on that approach (see The Mythical Man-Month for details).  At some point, however, another threshold is reached: the cost of maintaining the operation of the system grows to the point where it is more expensive than the operational value of the system.  Again, the business can make a hard decision, but it is in a worse place to do so: to replace the system (either by re-writing or buying a packaged solution), but without the operating margin to fund the replacement.

In his articles, Kane Mar describes this like so:

It’s pretty clear that a company in this situation has some difficult decisions ahead. There may be some temporary solution that would allow [a company] to use the existing system while building a new product, [A company] may decide to borrow money to fund the rewrite, or [a company] may want to consider returning any remaining value to their shareholders.

In other words, refactor or die.

Refactoring and Business

Refactoring and Business Success - Growth ChartIn the Scrum Master and Product Owner classes that we teach, this topic comes up frequently: how does the business account for refactoring?  How do we “govern” it?  How do we make good decisions about refactoring?

There are a few principles that are important in helping to answer these questions.  All of these principles assume that we are talking about refactoring in an Agile team using a framework like Scrum, OpenAgile, or Kanban.

Refactoring Principle One: Keep It Small

Refactoring is safest and cheapest when it is done in many small increments rather than in large batches.  The worst extreme is the complete system re-write refactoring.  The best refactoring activities take seconds or minutes to execute.  Small refactorings create a constant modest “overhead” in the work of the team.  This overhead then becomes a natural part of the pace of the team.

Not all refactoring moves can be kept so small.  For example, upgrading a component or module from a third party might show that your system has many dependencies on that module.  In this case, efforts should be made to allow your system to use both the old and the new versions of the component simultaneously.  This allows your system to be partially refactored.  In other words, to break a large refactoring into many small refactorings.  This, in turn, may force you to refactor your system to be more modular in its dependencies.

Another common problem with keeping refactorings small is the re-write problem.  Your own system may have a major component that needs to be re-written.  Again, finding creative technical means to allow for incremental refactoring of the component is crucial.  This can often mean having temporary structures in your system to allow for the old and new parts to work harmoniously.  One system that I was working on had to have two separate database platforms with some shared data in order to enable this “bi-modal” operation.

Refactoring Principle Two: Business Catalysts

When is the earliest that a refactoring should be done? Not whenever the technical team wants to do it.  Instead, the technical team needs to use business requests as catalysts for refactoring.  If the business needs a new feature, then refactoring should only be done on those parts of the system that are required to enable that feature.  In other words, don’t refactor the whole user interface, just refactor the parts that relate to the specific business request.

Again, there can be exceptions to doing this… but only in the sense that some refactorings might be delayed until a later date.  This is tricky: we want to make sure that we are not accumulating technical debt or creating legacy code.  So, instead, we need to allow the technical team to refactor when they detect duplication.  Duplication of code, data or structure in the system.  A business request might impact a particular part of the system and the team sees how it might be necessary to refactor a large swath of the system as a result.  But, the cost of doing so is not yet justified: the single request is not enough of a catalyst, and the team can also choose a simple temporary solution.  Later, the business makes another request that also implies the same large refactoring.  Now is the time to seriously consider it.  It is now a question of duplication of another simple temporary solution. The business may not be happy with the extra expense of the large refactoring so the principle of keeping it small still applies.  However, the technical team must also be willing to push back to the business under the right circumstances.

Refactoring Principle Three: Team Cohesion

Teamwork in Agile requires high levels of communication and collaboration.  In refactoring work, teamwork applies just as much as in any other activity.  Here, it is critical that all members of the team have a unified understanding of the principles and purpose of refactoring.  But that is just the first level of team cohesion around refactoring.

The next level of team cohesion comes in the tools, techniques and practices that a team uses in refactoring.  Examples include the unit testing frameworks, the mocking frameworks, the automation provided by development tools, continuous integration, and perhaps most importantly, the team working agreements about standard objectives of refactoring.  This last idea is best expressed by the concept of refactoring to patterns.

The highest level of team cohesion in refactoring comes from collective code ownership and trust.  Usually, this is built from practices such as pair programming or mob programming.  These practices create deep levels of shared understanding among team members.  This shared understanding leads to self-organizing behaviour in which team members make independent decisions that they know the other team members will support.  It also impacts research and learning processes so that teams can do experiments and try alternatives quickly.  All of which leads to the ability to do refactoring, large and small, quickly and without fear.

Refactoring Principle Four: Transparency

In many ways, this is the simplest refactoring principle: the team needs to be completely open and honest with all stakeholders about the cost of refactoring.  This can be difficult at first.  Another analogy helps to see the value of this.  A surgeon does not hide the fact that care is put into creating a clean operating environment: washing hands, sterilizing instruments, wearing face masks and hair covers, restricted spaces, etc.  In fact, all of those things contribute to the cost of surgery.  A surgeon is a professional who has solid reasons for doing all those things and is open about the need for them.  Likewise, software professionals need to be open about the costs of refactoring.  This comes back to the main point of the first part of this article: hidden and deferred costs will still need to be paid… but with interest.  Software professionals are up-front about the costs because doing so both minimizes the costs and gives stakeholders important information to make decisions.

The challenge for business stakeholders is to accept the costs.  Respecting the team and trusting their decisions can sometimes be very hard.  Teams sometimes make mistakes too, which complicates trust-building.  The business stakeholders (for example, the Product Owner), must allow the team freedom to do refactoring.  Ideally, it is continuous, small, and low-level.  But once in a while, a team will have to do a large refactoring.  How do you know if the cost is legitimate?  Unfortunately, as a non-technical stakeholder, you can’t know with certainty.  However, there are a few factors that can help you understand the cost and it’s legitimacy, namely, the principles that are described here.

If the refactoring is small, it is more likely to be legitimate.

If the refactoring is in response to a business catalyst, it is more likely to be legitimate.

If the refactoring is reflective of team cohesion, it is more likely to be legitimate.

And, of course, if the refactoring is made transparent, it is more likely to be legitimate.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

YouTube Video: What is Real Agility?

Learn more about transforming people, process and culture with the Real Agility Program

Many organizations are attempting to use Agile methods.  Banks, telecom companies, government agencies, and all manner of mid-size and small organizations.  Most of these attempts are limited in that they think of Agile as a solution instead of as a culture.  In this video, I explore some of the conditions for creating Real Agility.

This is the first video in a series of eleven that is oriented towards what managers need to know to create Real Agility in their organizations.  The final two videos in the series are going to be content exclusively available to subscribers to our Real Agility Newsletter.  Those final two videos are about “Dealing with Crisis” and “The Knowing-Doing Gap”.  (Our newsletter also includes other great content including interviews – we are featuring an interview with Mary and Tom Poppendieck in just a few weeks!)


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

What Do Strong Companies Hire For – Skills, or “Something Else?”

Learn more about transforming people, process and culture with the Real Agility Program

Perhaps you’ve experienced this…You go all revved up to a job interview with your beautiful resume in hand outlining all your accomplishments, believing you have all the right training, skills and experience…but you’re not chosen for the position. You cannot understand why.

Advertising guru and author, Simon Sinek, explains: “Weak companies hire the right experience to do the job. Strong companies hire the right person to join their team.”

Teamwork is becoming the hallmark of most successful businesses and organizations. We have entered an age where cooperation and working together is a vital necessity. No longer is the individual star performer going to do it for an organization. That’s not enough. Everyone needs to have the same vision, the same values, the same feeling of being valued. The demands on companies is just too great for one or two individuals to lead the way. Everyone must be a leader.

How can one show a potential employer that you are a team player? That you have great consultative and cooperative skills? That you’re willing to learn from everyone around you? Is this something that can be reflected in your personality?

“A recent international study surveyed more than 500 business leaders and asked them what sets great employees apart. The researchers wanted to know why some people are more successful than others at work, and the answers were surprising; leaders chose “personality” as the leading reason. Notably, 78% of leaders said personality sets great employees apart, more than cultural fit (53%) and even an employee’s skills (39%).” http://www.linkedin.com/pulse/do-you-have-right-personality-successful-dr-travis-bradberry

Forbes Magazine has published online articles about the hiring process which are fairly old-school, even wishy-washy. Writers talk about knowing the clear skill-sets a company is looking for, and having a detailed scorecard that defines the performance objectives for the position. They also discuss qualities of behaviour, but do not define behaviour in any specific way. Their expertise falls short in looking at personality, team-building qualities, and desire to learn, change and adapt.

Agile is the leading team-oriented methodology being adopted by the best and the brightest organizations in the world, such as Google and Apple. Agile teaches its participants to reflect, act and learn.

This is a kind of life-agility that’s needed in every realm we function in, whether as spouses, parents, employees, or members of our communities.

What do you hire for?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Teams and their proximity to the final user

Learn more about transforming people, process and culture with the Real Agility Program

A great, simple post from Mike Bowler…

Time: Teams that are writing code today that will be used by their customers tomorrow are very focused on what the customers actually need. Teams that are writing code today that won’t be seen by a customer for six months are less engaged.

https://www.linkedin.com/pulse/why-teams-care-mike-bowler

Mike Caspar
Passionate About Agile


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Agile Transformation Metrics

Learn more about transforming people, process and culture with the Real Agility Program

TL;DR

When asked to provide metrics to assess “how well” an Agile transformation is going, re-frame the discussion around measuring changes in the impact the IT organization is having (or not) on it’s Business environment, and define a small set of “fitness for purpose” metrics.

The Inevitable Question about Agile Transformation Metrics

Sooner or later, as an IT organization embarks on a transformation towards Agile mindset and practices, someone will be asked to provide “hard evidence” that the effort is paying off, and the conclusion will be that metrics is the vehicle to satisfy that request. What are your Agile transformation metrics?

It’s been my experience that this request usually leads to a discussion about measuring the specific Agile initiatives the IT organization has launched. In organizations where the emphasis has been around engineering disciplines, such metrics might be things like unit test code coverage, or integration build times. If the focus  was around teams and process, then counting number of teams “converted” to Scrum, or people sent to Scrum Master training may appear as the choice.

While those measurement might be useful indicators in some context, they have two problems. First, they are akin to measuring the performance of the car engine without looking outside the window; the engine might be performing well, but if the car doesn’t have the wheels attached, we’re going nowhere. More importantly, though, these figures are usually meaningless for Business stakeholders, who are the ones usually asking for them in the first place.  Agile transformation metrics need to be meaningful to the Business.

Re-framing the Agile Transformation Metrics Question

Agile transformation efforts can be very costly exercises, therefore it is legitimate to ask about the results of such endeavour. The important thing to realize, though, is that this question is really equivalent to another question: “is the IT organization improving its impact on its Business environment.” Another way to put it is, borrowing from the terminology used by the Kanban community: “is the IT organization becoming more and more fit for purpose?” Answering this question, of course, requires a clear understanding of what is that the Business expects from its interactions with IT.

The IT organization can be seen as providing various services to customers. Arguably, if IT has decided to “transform” in some way (perhaps by moving towards an Agile mindset), it’s doing so to improve its impact on those customers, so this is what needs to be measured to know “how the transformation” is going.

Some of those customers are different areas of the organization (like Finance, or HR.) But it doesn’t stop there, because the Business’ engagement with IT doesn’t have value for its own sake. Ultimately, the Business is using IT as a way to optimize its operations so that it can provide external customers with more effective products and services. Moreover, IT is these days the direct channel through which those products and services are delivered to external customers (for example, through web sites and mobile applications.) Therefore, the concept of “fitness for purpose” of the IT organization can be extended to consider the fitness for purpose of the Business respect the external customers it intends to serve.

Defining the “Agile” Transformation Metrics

Measuring “agile transformation success” really means measuring the success of the exchanges between IT and the Business, and between the Business and its external customers.  Measuring the internal processes and practices that IT puts in place as part of that “transformation” is beside the point. This implies starting with a careful definition of the boundaries that delineate the exchanges to be measured. There might be more to external customer fitness for purpose than IT operations, for example, and that needs to be considered when defining Agile transformation metrics, especially if we’re later going to be drawing causation conclusions.

Defining Agile transformation metrics will be, of course,  a highly contextual exercise because every business organization is different.  But we can, however, draw again from the Kanban community for some general guidelines on what to look for. Their thought leaders talk about classifying metrics into 3 categories: fitness for purpose metrics, health indicators and improvement drivers.  Using this framework, when talking about “agile transformation metrics” we are referring mainly to the first category, and perhaps a bit to the second. Based on those, improvement initiatives can be put in place, and perhaps driven with metrics belonging to the third category.

A fitness for purpose metric (also known as KPI) is an indicator of something a customer will care about. This is a key distinction: if the metric is not easily recognizable and meaningful for the customer, then it’s not a KPI. Another key characteristic is that a minimum threshold for its value can be defined: if the metric goes below the threshold, the Business is putting the relation with its customers at risk (perhaps they will walk away, initiate legal actions, etc.). In other words, the Business is no longer “fit for purpose”. We can then measure the effectiveness of the “agile transformation” by analyzing how KPI values over time compare to their respective thresholds. A typical KPI is delivery time, measured from the moment a customer request is accepted and committed to, until the moment it’s delivered to production.  This is usually a good Agile transformation metric.

Health indicators are metrics that are inwards facing. Customers don’t really care about them (or even understand), but they indicate how a given aspect of the system is operating. The key characteristic is that they are not directly actionable; they only provide information that needs to be analyzed and put in context. As the value of a health indicator changes, we can draw some conclusions about how the system works, or explain why something is happening (or not), but it doesn’t necessarily leads to concrete action. Defect count is an example of this. Customers will certainly care about quality of the product, and we can make inferences about that quality by looking at how many defects we have, but the absolute number of defects will not necessarily make the product more or less fit for purpose. It may happen that customers consider the current quality to be “good enough”, irrespective of the number of defects.

Finally, improvement driver metrics are metrics put in place to influence behaviour towards a particular change. Their key characteristic is that they are temporary: we set a target on them and once the target is achieved, the metric is no longer necessary. The reason for this is related to the unintended behaviours that a metric might encourage in people, which may lead to locally optimizing the metric at the expense of other aspects, leading to global sub-optimization of the system. An example is unit testing code coverage: if we have determined that a given service is not fit for purpose and the cause is related to poor unit test coverage, then establishing a target for minimum coverage may influence developers to work on adding tests to reverse the situation.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Pitfall of Scrum: Assigning Tasks

Learn more about transforming people, process and culture with the Real Agility Program

Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!!  It is better to wait for someone to step up than to “take over” and start assigning tasks.

Assigning tasks can be overt or subtle.  Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”

In the Scrum Guide, a partial definition of self-organizing is given:

Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

A more formal definition of the concept of “self-organizing” can be found here:

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.

The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.

What If One Person Isn’t Working?

People who are managers are often worried about this.  What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing?  Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.

Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.

Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs.  Assigning tasks doesn’t make a person more productive.

What If There is One Task No One Wants to Do?

Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!

There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.

And, of course, there’s always the Sprint Retrospective!

Why Self-Organize – Why Is Assigning Tasks Bad?

Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.

Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees).  Even if this is true, it is still easy for a person to take offence.  However, most of the time it is not true.  People know themselves best.  People are best at assigning tasks to themselves.  And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.

The ScrumMaster and Assigning Tasks

The ScrumMaster plays an important role in Scrum.  Part of this role is to encourage self-organization on a team.  The ScrumMaster should never be assigning tasks to team members under any circumstances.  And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks.  If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening.  The ScrumMaster needs to be constantly aware of the activity on his or her team.

I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 3: Working Software over Comprehensive Documentation

Learn more about transforming people, process and culture with the Real Agility Program

How much documentation does it take to run a project with ten people working for six months?  For some organizations it takes way too much:

Photo of heavy documentation for software project

This binder (about 3 or 4 inches thick) is all the documentation associated with such a project.  In looking carefully at the project, creating the documentation took far more time than the time spent on designing, writing and testing the software.  Yet, the documentation does not produce any value.  Only the software produces value.  The Agile Manifesto, asks us to focus on the outcome (working software) and to make tradeoffs to minimize the means (comprehensive documentation).

The Agile Manifesto asks us to challenge our assumptions about documentation.  In many work environments, documentation is an attempt to address some interesting and important needs:

  • Knowledge sharing among stakeholders and the people working on a project.
  • Knowledge sharing across time as people come in and out of a project.
  • Verification and traceability for contracts or other compliance needs.
  • Decision-making and analysis for business and technical problems.
  • Management oversight and control.
  • Various aspects of individual accountability.

Documentation is usually heavier (more comprehensive) the more the following circumstances exist in an organization:

  • Geographical distribution of people.
  • Lack of trust between people, departments or organizations.
  • Regulated work environments.
  • Depth of management hierarchy.
  • Number of people directly and indirectly involved.
  • Knowledge and skill sets highly segregated between people.
  • Culture of respect for written texts.

Working Software

What if the software itself could address the needs that often documentation is used to address?  Let’s look at them in turn:

  • Knowledge sharing among stakeholders and the people working on a project.
    If the software is functional at all stages, as supported by Agile methods such as Scrum and Extreme Programming, then the software becomes an effective representation of the knowledge of all the people who have participated in building it.
  • Knowledge sharing across time as people come in and out of a project.
    Software that is technically excellent is often easier to understand for people who are new to it.  For example, excellence in user experience and design means new users can get up to speed on software faster.  Use of good design patterns and automated testing allows new developers to understand existing software easily.
  • Verification and traceability for contracts or other compliance needs.
    Test-driven development (code) and specification by example (scripting and code) are forms of traceable, executable documentation that easily stay in-sync with the underlying software system.
  • Decision-making and analysis for business and technical problems.
    In particular, diagrams can help a great deal here.  However, electronic tools for creating such diagrams can be slow and awkward.  Consider the practice of Agile Modelling (basically using a whiteboard and taking photos) as a good alternative to precise technical diagramming if you are doing problem-solving.
  • Management oversight and control.
    Reports and metrics drive much of the traditional documentation in an organization.  Simplifying reports and metrics often leads to a clearer picture of what is going on, reduces the opportunities to “game” the system, and always results in lower levels of documentation.  As well, some reports and metrics can be generated 100% through automated means.  All that said, the fundamental premise in the Agile manifesto is that management should base decisions on what is actually built – the “Working software” by looking at it and using it.
  • Various aspects of individual accountability.
    If you really need this, a good version control system can give you the information for this.  Sign-offs and other types of accountability documentation are typically just waste that doesn’t actually help in process improvement.  Most people who are in high-compliance environments already have licenses and/or security clearances that provide this accountability.  If you software is working, however, then this isn’t even a concern as trust is built and bureaucracy can be reduced.

In my recent training programs as research for this article, I have surveyed over 100 people on one aspect of documentation – code documentation.  Every individual surveyed is either currently coding or has a coding background, and every single person had the same answer to a simple scenario question:

Imagine that you have just joined a new organization and you are about to start working as a software developer.  One of the existing team members comes up to you and introduces himself.  He has with him a piece of paper with a complicated-looking diagram and a full binder that looks to be holding about 250 pages.  He asks you, “you need to get up to speed quickly on our existing system – we’re starting you coding tomorrow – would you prefer to go over the architecture diagram with me or would you prefer to review the detailed specifications and design documents.” He indicates the one-page diagram and the binder respectively.  Which would you prefer?

(I’ve put up a Survey Monkey one-question survey: Code Documentation Preference to extend the reach of this question.  It should take you all of 60 seconds to do it.  I’ll post results when I write the next Agile Manifesto essay in a month or two.)

The fact that everyone answers the same way is interesting.  What is even more interesting to me is that if you think through this scenario, it is actually almost the worst-case scenario where you might want documentation for your developers.  That means that in “better” cases where documentation for developers may not be as urgent or necessary, then the approach of just going to talk with someone is a lot better.

Documentation and Maps

The problem with documentation is the same problem we have with maps: “the map is not the territory” (quote from the wisdom of my father, Garry Berteig).  We sometimes forget this simple idea.  When we look at, say, Google Maps, we always have in the back of our consciousness that the map is just a guide and it is not a guarantee.  We know that if we arrive at a place, we will see the richness of the real world, not the simplified lines and colours of a map.  We don’t consider maps as legally binding contracts (usually).  We use maps to orient ourselves… as we look around at our reality.  We can share directions using maps, but we don’t share purpose or problems with maps.  And finally, maps assume that physical reality is changing relatively slowly (even Google Maps).

Many times when we create documentation in organizations, however, we get confused about the map versus the territory.

Agility and Documentation

Of course, code is a funny thing: all code is documentation too.  The code is not the behaviour.  But in software, code (e.g. Java, ASM, Scheme, Prolog, Python, etc.) is as close as possible to the perfect map.  Software is (mostly) deterministic.  Software (mostly) doesn’t change itself.  Software (mostly) runs in a state absent from in-place human changes to that software.  Software (mostly) runs on a system (virtual or physical) that has stable characteristics.  The code we write is a map.  From this perspective, documentation becomes even less important if we have people that already understand the language(s)/platform(s) deeply.


This essay is a continuation of my series on the Agile Manifesto.  The previous two essays are “Value and Values” and “Individuals and Interactions over Processes and Tools“.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail