Software Results

How Do You Define Leadership?

noreply@blogger.com (Dave Moran) — Wed, 30 May 2012 10:00:00 +0000

Some people feel that because they have a title, this makes them a leader. However, the big test of leadership is in how you answer this question: Would you have any followers if you didn’t have a title?

Leaders have followers, and if you don’t have true followers, then what you really have with your title is positional authority. Following is a voluntary act. This means that leaders can exist within organizations even though they aren’t in formal positions of authority; informal lines of leadership exists where leadership is conferred on certain individuals by others, such as in recognition of knowledge and expertise in a given area.

When it comes to formal lines of leadership, people are placed in positions of authority – management roles – in order to get things done. Not just as individual contributors, but to orchestrate and leverage the collective talents of the people who make up an organization.

The immediate objective is to reach today’s goals. Getting something done in the short-term is actually the easy part. The other half of the equation is to develop the people and the organization, to increase an organization’s capacity and ability to reach new heights tomorrow. The rub is that while positional authority literally puts you in a position to get things done, it is how you go about getting those things done that will define you as a leader.

Let’s hope that you don’t end up defined – as Bob Sutton has points out in his book, The No Asshole Rule – on the "certified" list of truly unpleasant people to work for. Unfortunately, as Bob Sutton points out in his book: “…some people do deserve to be certified as assholes because they are consistently nasty across places and times.” If you’ve spent enough time in the workforce, you probably have bumped into at least one of these in your day. I have, and they are truly toxic.

But let’s be fair, to earn this title you must be consistent in your behavior over a period of time. You need to make one person after another feel “…belittled, put down, humiliated, disrespected, oppressed, de-energized, and generally worse about themselves.”

Someone like this can single-handedly decrease engagement and productivity (because people are more focused on protecting themselves than anything else) while increasing job dissatisfaction and turnover with extraordinary speed. It amazes me how people like this not only move into management positions in the first place, but manage to job-hop their way into executive positions and remain as toxic as ever. But I digress…

What about the classic distinction between being a manager and a leader? In today’s turbulent business climate that demands greater innovation and engagement in order for businesses to survive, let alone thrive, I don’t believe in Warren Bennis’ differentiation between a manager and a leader where, “The manager does things right; the leader does the right thing.” Not anymore.

At one point in time that was true. But we can’t let it be true any longer. The pace of business today demands more. Organizations need greater capacity in determining what the right thing to do is along with possessing the ability to swiftly transition to executing well (doing things right). We can’t afford the overhead and latency involved by keeping the two separate.

Today’s organizations cannot solely be paragons of efficiency, not when efficiency is defined by yesterday’s way of doing business. Today, we need our organizations to be effective and efficient, with the ability to quickly and reliably adapt to the rapidly changing circumstances of the business. To achieve this, organizations must have those in leadership positions that posses the qualities that allow them to guide organizations into being nimble, responsive and adaptive, to reliably execute while contending with challenging and changing conditions.

These days, leaders must be able to improve both the system and the people, to manage and lead. To coach and guide others who are new to evaluating systems problems and making improvements for themselves. The result will be a more adaptive, resilient organization capable of handling whatever challenges comes its way.

Changing Mindsets: One Key to Successful Organizational Change

noreply@blogger.com (Dave Moran) — Wed, 23 May 2012 10:26:00 +0000

In a recent post, Learning Organizations Require Certain Conditions, I talked about how – at a personal level – we need a growth mindset versus a fixed mindset. If your goal is to stretch yourself and expand your capabilities, you need to be willing to put yourself in new situations that a growth mindset welcomes.

At an organizational level, a significant challenge for leaders who are driving change is making that change stick. This means changing the mindsets of those in the organization, shifting thinking towards something new while overcoming that inevitable resistance. People need to accept and buy into it. Change must move past being “something new” to the “new norm.”

How do you get there?

I found some solid advice in the book Beyond Performance by Colin Price and Scott Keller.

The first piece of advice is simple and practical: “Shifting mindsets is a gradual process, and we'd advise organizations not to take on too many at once.”

Here’s a question for you: Should you focus on what is wrong or what you are doing right? A study performed by the University of Wisconsin provides the answer. The study involved the filming of two bowling teams. Each team was given its own video to study, but one team received a video that showed only its mistakes; the other received a video that showed only its successes. After seeing the videos, the team that studied its successes improved its score by twice as much as the team that studied its mistakes.

In a corporate context, focusing exclusively on what is wrong has been demonstrated to create fatigue and resistance. That does not mean that you ignore your problems, but to do as T. H. White, former president of GTE Telephone Operations, says: “If we dissect what we do right and apply the lessons to what we do wrong, we can solve our problems and energize the organization at the same time. … We cannot ignore problems, but we just need to approach them from the other side.”

Price and Keller advocate using the “influence model,” which identifies four major levers that leaders can use to shift employee mindsets on a wide scale:

A compelling story. Can employees say, “I know what is expected of me, I agree with it, and I want to do it?”

Reinforcement mechanisms. Do the organization's formal mechanisms reinforce the shifts in mindset that employees are being asked to make?

Skills required for change. Do employees have the skills they need to think and behave in the new way?

Role modeling. Do employees see their leaders, colleagues, and staff thinking and behaving in the new way?

And finally (and always), don’t micro-manage! As Price and Keller state in Beyond Performance, “Micro-programming every facet of a transformation will only bog the effort down in energy-sapping bureaucracy. What we're after is coherence without rigidity.”

Don’t Let Fear of Failure Prevent You from Starting

noreply@blogger.com (Dave Moran) — Fri, 18 May 2012 10:19:00 +0000

We all enjoy success and the desire to succeed over failing is definitely a motivator, but we shouldn’t let fear overwhelm us or limit our growth, either. If we are going to stretch ourselves and reach new heights, we need to push our limits -- without getting in over our heads.

There’s a balance that needs to be struck. We need to have far-reaching, motivational goals, but we shouldn’t be placing self-imposed limitations on our potential. We need to nurture our ambition to scale new mountains without reaching for too much, too soon, because being overwhelmed can cause us to give up.

You can’t make the cut from novice to expert in one leap. But you can develop expertise over a period of time through dedicated effort and coaching from others who have developed expertise. And yes, you’ll experience some failures – let’s call them setbacks – along the way. Some of those setbacks may be out of you control while others will reveal your current limitations. It is up to you to reflect and learn what you need to do to expand your capabilities to move past them. Success doesn’t happen by accident (most of the time); you need a game plan.

Defining success and planning for it is critical. For example, do you define success as publishing a book or publishing a best-seller? These days it is an easy thing to self-publish – which meets the success criteria of “publishing a book.” It is quite another goal – a more ambitious one that requires greater planning – to publish a best seller.

You could start pecking away at writing your book now, putting everything that you have into it. If you lack any prior writing experience, you could be setting yourself up for failure. You’re trying to make lightening strike – not that it doesn’t happen every once in a while, but the odds are not in your favor. Very few first-time authors make it big on their first try.

Instead, you could channel that ambition by writing some articles (or blogs, or both). This gives you the opportunity to develop your writing talent while you simultaneously learn about what appeals and sells to your target market. In doing so you will receive candid feedback early and often so that you can learn and adapt – an opportunity that you won’t have by writing a book in isolation. Plus you’ll be building name recognition along the way that will contribute to your overall goal of writing that best-seller.

Don’t be afraid to dream big, just don’t be afraid to start! Be honest with yourself and seek to reveal your current limitations, then reflect and determine what you need to do to improve and moved past those limitations. It’s not about limiting your potential or your aspirations; it’s about realizing a long-term goal in stages, evolving and improving our capabilities over time to reach that new place. Whatever you do, don’t be left sitting on the sidelines watching and wishing that you had taken action!

I’ve found that I really enjoy writing, and I feel that I’ve been refining and improving my writing these past few years with this blog. And while I’ve published some articles here and there the past few years as well, my current aspiration is to increase my work as a professional writer. This means writing more articles and writing a book or two (I have some ideas). My plan is this:

Since I’m still working and time is scarce, I need to cut my posting to once per week on this blog. (In order to do new things, it helps to make room to do them.) I’m going to shift to Wednesday postings.
I’ll continue to post once per month on VersionOne’s Agile Management Blog.
I’ll start writing and publishing articles, targeting to publish half-a-dozen per year.
I’ll write a small eBook and self-publish that before the summer is out.
I’ll develop an outline and a few sample chapters of another book by the end of the year.

I don’t expect to publish a best-seller, but I do hope for modest sales, and my goal is to publish a book that readers find valuable. That’s my game plan, what is yours?

Is Fear a Motivator?

noreply@blogger.com (Dave Moran) — Tue, 15 May 2012 10:00:00 +0000

There are definitely some in management positions who think so. The rationale being that it keeps people focused on their jobs and doing the “right” things. If people fear the negative consequences for failing to perform, they’ll be motivated to give it their all, right?

Not from my experience. Fear may be a convenient motivational lever, but “management by fear” will seriously constrain organizational performance. Fear of failure in the workplace brings anxiety and stress that drains people of energy. It causes people to play it safe and avoid stretching themselves. Fear can contribute to failure because the negative feelings and related stress gets the better of people and causes them to freeze up.

Fear inhibits people from being truly engaged – in an age where we want more engagement. What are some of the things that people are scared of in the workplace? In his book, The Art of Engagement, Jim Haudan provides the following list:

We’re afraid that our contributions aren’t really valued.
We’re afraid that our personal beliefs don’t align with those of the company.
We’re afraid that we won’t be able to adapt to changes in the way we work.
We’re afraid that we won’t have a safe place to practice new skills.
We don’t feel that it’s safe to say what we really think.
We don’t think it’s safe to suggest better ways of doing things.
We don’t know how to disagree and not become branded “a problem.”

Managers should keep these things in mind, asking themselves if they are creating an environment that encourages people to feel safe, to talk openly without fear of reprisal, to feel connected to the company and others within the company. Barking out orders and demanding compliance may get things done, but doing so won’t engage your employees. You’ll leave untapped productivity on the table.

People can be trusted to perform far more than most management systems allow for today. A greater level of autonomy is possible – and more productive – as Agile development demonstrates. However, autonomy doesn’t mean cutting people lose and ignoring them.

In order to produce that steady stream of value, autonomous teams need to be equipped with a solid understanding of the business objectives, they need to be closer to the customer and understand the needs of the customer. And as the list above demonstrates, they need to be connected with the business in a way that makes them feel safe, valued, and trusted.

Managers who lack experience with autonomy are naturally apprehensive about it. They doubt that it will work – at least “in their environment.” They are afraid of losing control because their necks are on the line to produce. If you are in this camp, try this experiment.

Learning Organizations Require Certain Conditions

noreply@blogger.com (Dave Moran) — Fri, 11 May 2012 10:00:00 +0000

As I noted at the beginning of my last post, Principle 14 of the Toyota Way states that become a learning organization is achieved through relentless reflection (hansei) and continuous improvement (kaizen). What does it take to make reflection and continuous improvement work?

There are conditions related to personal and organizational dynamics that must be in place to foster learning. For a start, people and organizations have to want to improve, which means being able to take an honest, realistic look in the mirror.

At a personal level, people need a growth mindset versus a fixed mindset. People with a fixed mindset tend to believe that “you are who you are” and there isn’t much that can be done to change that, whereas those with a growth mindset believe that people can change – substantially, if they so desire. Another important distinction to understand is that people with a fixed mindset react to setbacks differently than those with a fixed mindset.

Dr. Carol Dweck has studied the different mindsets extensively, and in one enlightening study she examined how schoolchildren reacted to getting a low grade on an exam. Students with a fixed mindset felt that they were failures. Those with the growth mindset said – and genuinely felt – that they needed to try harder next time.

A low grade was a blip on the radar to those with a growth mindset, simply a signal to make an adjustment in their journey to maximize their potential. Those with a fixed mindset tended to view a low grade as an indictment that they weren’t smart and allowed a low grade to almost literally halt them in their tracks.

The reason for this is that people with a fixed mindset tend to look for situations that confirm their current abilities while shying away from situations that don’t, and they get defensive about any shortcomings or failures they encounter. Growing, however, means putting yourself in new situations and embracing the opportunity to stretch and expand your abilities, something those with a growth mindset are willing and able to do without hesitation.

Being aware of what type of mindset you have is an excellent start, and if you have a fixed mindset changing your outlook – and soliciting the help and support of others – can help you to see where you are judging yourself unfairly and limiting yourself in the process. Managers need to be alert to the mindsets of their people to coach them effectively. As a manager, your approach will obviously be very different based on the exhibited mindset of the individual that you are coaching.

The approach that leaders take with an organization as a whole is as equally important. When it comes to being a learning organization in general, leaders definitely set the tone. Let’s say that a software team was unable to complete some task or delver a feature as planned. Do they feel pressured to defend why they were not able to complete the work because they are being judged and evaluated?

Leaders need to keep in mind that when obstacles appear, people need to experiment and learn to overcome those obstacles. We all need to be working towards aggressive targets, but being judged and evaluated on a binary “you succeeded or failed” scale does not foster a learning environment. The goal is to collectively reach new heights as an organization, and that means everyone is participating in getting there. Leaders need to participate in the process as well, doing more than acting solely as judge and jury.

Introducing informality into the workplace is another great way to encourage change and visibly demonstrate that the organization is willing to learn and adapt. Scrum or Kanban boards using sticky notes versus electronic tools are a great example of informality. Exclusive use of detailed project plans captured in tools tend reinforce the notion of work being formal, scheduled and “locked down” without the option of easily making a change.

Using a framework like Scrum instead of a fully codified process is another way of engaging people. Scrum provides just enough guidance as opposed to a rigid process where compliance is expected and any deviation from the process is actively discouraged. When people have influence and control over their work, they are more engaged and productive; in fact it can be counter-productive when everything is strictly defined because judgment and adaptation to specific circumstances on the ground can and will take a back seat to process.

When it comes to the physical work environment, open, comfortable workspaces are ideal. They aren’t meant to provide a laid-back, country-club environment. These days workplaces have enough stress associated with the mountain of work that people face; they don’t need stiff, sterile cubicles reinforcing rigid organizational structures that stifle collaboration and interaction. Overall, informality helps to relax people so that they can concentrate on what needs to be done, plus it creates a feeling of safety for people to speak openly and candidly.

And when it comes to working with people and teams, leaders should engage people as often as possible in their own setting to learn what is really going on – using the Go and See Lean approach. As I noted above, leaders should not judge, but participate with people and teams on reaching aggressive goals.

Without a certain amount of informality and a demonstrated willingness to learn and adapt, fear and caution win out over stretching and growing. Punishing failure or even worse – perceived failure – will send a strong message to play it safe and negotiate goals and performance measurements down, not up. Courage, curiosity, and the willingness to try new things must win out over defensiveness and a fear of failure. A fundamental truth is that you’ll never reach to top without stretching for it.

The Toyota Path to Competitiveness

noreply@blogger.com (Dave Moran) — Tue, 08 May 2012 10:00:00 +0000

Principle 14 of the Toyota Way states: Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).

How much do you reflect as an individual? How about as an organization?

Time for reflection is definitely scarce in most organizations. In his book The Way We're Working Isn't Working, Tony Schwartz quotes Harvard psychologists Robert Kegan and Lisa Lahey, who observe that, “We are already the most overinformed, underreflective people in the history of civilization.” Schwartz argues that, “The relentless urgency that characterizes most corporate cultures undermines creativity, quality, engagement, thoughtful deliberation, and, ultimately, performance.”

He’s right. These days we’re continually pressed for time, with little to no time remaining to reflect. We’re doing more with less – and this at times this means more than just doing more with less people, it means that we’re doing more with less thinking about what we're doing now, let alone reflecting on what has already transpired or how we could approach what we're about to do differently. As the Toyota Way articulates, reflection is a key aspect of become a learning organization. The lack thereof will impact us individually as well as challenge the long-term viability of our company.

Agile development, with its philosophy of sustainable development coupled with time baked in for conducting a retrospective (a la Scrum), promotes reflection and improvement. However it’s important for people to understand that this isn’t simply a meeting that should be held because the Scrum Guide tells you to do it, nor should you confine yourself to looking through the lens of what you do today.

What we really want to do is to change our current thinking and develop new behavior patterns and approaches to our work. Retrospectives are a first step in engaging everyone in developing a deeper understanding of the customer and the work processes that are (or should be) designed to deliver value to the customer.

From a leadership standpoint, it is important to understand that the goal is to go beyond improving the work system; we want to improve our people. Mike Rother in his book, Toyota Kata notes that, “The primary task of Toyota’s managers and leaders is not to focus exclusively on improvement, but on increasing the improvement capability of people.”

As part of this, Rother points out that improving “puts considerable emphasis on how people tackle the details of a process, which is what generates the outcomes.” Toyota lives and breathes continuous improvement, training its people in using a PDCA, or plan-do-check-adjust (or act), approach to create those desirable outcomes.

Toyota also extends this continuous improvement mindset in its competitive approach to the marketplace. Toyota doesn’t disregard a promising opportunity because it doesn’t pass an initial cost-benefit analysis. Instead, management views the problem as one of nurturing that opportunity into profitability by “…getting people to work systematically and creatively at the detail level to do what is necessary to achieve ambitious target conditions.”

The message here is simple: numerical targets exist within Toyota, but they are used to define target conditions and not as targets in and of themselves. Learning organizations grow their people and organizational understanding in order to reach new targets that were formerly out of reach.

Mike Rother sums this up nicely in the Toyota Kata: “As far back as 1992, I learned from President Fujio Cho and members of his management team at Georgetown that Toyota steadfastly believes that organizational routines for improvement and adaptation, not quantitative/financial targets, define the pathway to competitive advantage and long-term organizational survival.”

Book Review: Scaling Lean & Agile Development

noreply@blogger.com (Dave Moran) — Fri, 04 May 2012 10:28:00 +0000

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
If you are looking for a book that discusses why it is more important to be agile than to do agile, this book is for you! Scaling Lean & Agile Development covers both the theory that supports Lean and Agile thinking along with practical advice on what to “try…” and “avoid…”

It is difficult to justice to a comprehensive book in a short review, but Larman and Vodde did an excellent job of combining their experience with extensive research to provide a comprehensive look at why Lean and Agile works and what it takes to change.

For example, thinking that Lean and Agile is only for developers, “…leads to no real change and no real result, and the eventual predictable abandonment of lean principles or agile development because ‘that doesn’t work.’” In fact, “it is vital to appreciate that organizational agility cannot be achieved by a development team in isolation—it is a system challenge for organizational redesign.”

Larman and Vodde go on to explain: “If an engineering team has the technical capacity to adapt or change quickly, but requirements management, legal practices, product management, HR policies, site strategies, and deployment processes all emphasize rigidity, conformance to original plans, conformance to the status quo, and slow practices, then how can there be real agility?”

Agile teams surrounded by a non-agile organization are going to face challenges, without a doubt. I really took a liking to one observation that Larman and Vodde made: “’Agile’ is not a practice. It is a quality of the organization and its people to be adaptive, responsive, continually learning and evolving—to be agile, with the goal of competitive business success and rapid delivery of economically valuable products and knowledge.”

This means that Lean and agile thinking goes deeper that tools or techniques, or the elimination of waste; “As can been seen at Toyota, it is an enterprise system resting on the foundation of manager-teachers in lean thinking, with the pillars of respect for people and continuous improvement. Its successful introduction will take years and requires widespread education and coaching.”

And it will take years. We have a variety of deep-rooted behaviors and expectations to change. For example, consider the expectations many companies have around tools and reports, with managers and executives running companies from conference rooms. Larman and Vodde address how this needs to change in a Lean and agile culture:

“In a lean-thinking culture, all people, but especially managers—including senior managers—should not spend all their time in separate offices or meeting rooms, receiving information via reports, computers, management reporting tools, and status meetings. Rather, to know what is going on and help improve (by eliminating the distortion that comes from indirect information), management should frequently go to the place of real work and see and understand for themselves.”

And what about some of those agile tools that are out there? Larman and Vodde have this to say: “Tools—including most ‘agile tools’—are optimized for reporting rather than for real value work. Developers or POs find the tool awkward and report that it slows them down, but senior management see the reports they want—and obvious sub-optimization. Notice that such tools may inhibit the lean Go See practice.” – Enough said!

Moving on, another excellent piece of advice Scaling Lean & Agile Development offers concerns how to respond when dealing with the complexities and challenges of software development in a Lean and agile way: “Do not increase multitasking, or utilization rates to create the illusion that queues have been reduced and the system has improved; rather, improve the system so that the bottlenecks and other forces that create queues are removed.”

Increasing utilization is a common management tactic, but as Larman and Vodde point out, ”As utilization goes up in a system with lots of variability, average cycle time gets worse, not better.” This is because, “Resource management strategies that focus on high utilization of workers—a focus on watch the runners rather than watch the baton—create an environment in which people will create a large inventory of things (requirements, designs, code) in a push model.” Definitely NOT the way to go when applying Lean and agile thinking!

Other challenges – as the name of the book implies – deals with scaling Lean and agile development. One approach Larman and Vodde recommend is to, “Structure the product group primarily by requirement areas and related Scrum feature teams—a Requirement Area unit. Each unit has a requirement area manager whom the feature teams “report to.” His (or her) prime role is to support the new feature teams that join the area. He will probably also have work stemming from organizational policies such as budgeting, performance appraisals, and so forth.”

Granted, there are trade-offs associated with this approach, and the book discusses those as well. Another interesting challenge Scaling Lean & Agile Development tackles is with product portfolio management. The challenge is that, “Coarse-grained product prioritization leads to local optimization in which the low-priority items of a high-priority product are implemented instead of the essential items of a lower-priority product.”

The solution?

“Merge the Product Backlogs of different products into one Product Backlog for the whole company. The CEO acted as the Product Owner. When the organization has one Product Backlog and one Product Owner for the whole company, then the prioritization aspect of portfolio management and prioritizing the Scrum Product Backlog are the same activity. However, it is now done on the feature level—avoiding the previous local optimization.”

In closing, I found this book to be well-written, full of insight, advice and research that makes Scaling Lean & Agile Development something that every Lean and agile practitioner should have on their bookshelf (or Kindle library).

The Elegance of Scrum as Defined by BART Analysis

noreply@blogger.com (Dave Moran) — Tue, 01 May 2012 10:30:00 +0000

Not all adoptions begin with ideal staffing. At one point in time I was both a development manager and a Product Owner for one of our teams. Was this ideal? No. Does something like this happen in real life? Sure.

If you choose to operate where there is role overlap, make sure that you are clear about what role you are “playing” when dealing with questions or issues. For example, as a development manager it was fair game for me to discuss the design and implementation of the code with developers on the team who sought out my advice, but not so if I was operating as a Product Owner. I always called which hat I was wearing before diving in.

I made sure that I did because I didn’t want to cause confusion later, when we found a dedicated Product Owner for the team. I understood the boundaries, authorities, roles and tasks (BART) that should be respected for proper execution of the Scrum framework, and I wanted the team to understand them as well.

I was introduced to BART by Dan Mezick (listening to him speak about BART analysis more than once at agile events in Boston), which is a system for group analysis developed by Zachary Gabriel Green and René J. Molenkamp. BART analysis is a useful tool for understanding why Scrum works – and what you should understand before you start tinkering with it.

As a framework, Scrum is very effective because it addresses the elements of productive teamwork are articulated nicely in the book, The Wisdom of Teams by Jon R. Katzenbach and Douglas K. Smith:

"Team members must agree on who will do particular jobs, how schedules will be set and adhered to, what skills need to be developed, how continuing membership is to be earned, and how the group will make and modify decisions, including how and when to modify its approach to getting the job done."

Teams save time by implementing Scrum because they can quickly learn and implement the Scrum framework. Scrum defines the roles and protocols of team interaction so that teams don’t have to develop these each time for themselves, and once you apply BART analysis against the Scrum framework, you recognize the elegance of Scrum’s design.

The Scrum framework is both simple and powerful, which is due to it being crystal clear on each of the BART attributes:

The Scrum Roles are clearly defined.
The Boundaries between the Roles are clearly defined.
The Authority granted to each Role is clear.
Tasks are clearly defined.

Clarity is important because when these definitions are unclear there will be wasted time and effort due to confusion and contention. Consider what would happen if roles or tasks overlapped, or there wasn’t clarity on the tasks each that each role is responsible for. For a team to be productive, these issues would need to be worked out.

BART is a useful tool for managers to understand how other violations create confusion, like when a manager assigns tasks to Scrum team members. Yet this is what a traditional manager is used to doing! By providing an understanding of the Scrum framework coupled with an understanding of BART analysis, managers are equipped to understand why certain behaviors should be avoided.

Overall, BART analysis provides additional insight that is useful developing a deeper understanding of how and why the Scrum framework works. And for anyone considering tinkering with the workings of Scrum related to boundaries, authorities, roles, and tasks, it is worth keeping BART analysis in mind so that you don’t create overlap or confusion.

For additional information on BART analysis as it relates to Scrum, I refer you to Dan Mezick’s Agile2009 presentation.

Agile Teams Need to Guard Against Self-Mismanagement

noreply@blogger.com (Dave Moran) — Fri, 27 Apr 2012 10:00:00 +0000

Scrum is an excellent framework that provides a team with the requisite structure to address the complexities and challenges of software development while remaining completely open in terms of defining what the product is and how it will be implemented. A key tenet with agile and Scrum is that the team is in control of their work, and a framework like Scrum provides the necessary guidance for teams to coordinate and manage their work without being directed by someone else.

As simple as a framework like Scrum sounds, execution is harder than it appears. One danger is that people start adapting Scrum to meet their current ways of working instead of changing the way that they work. For Scrum to be of value it is important to look beyond the mechanics of the framework and embrace the Lean and agile thinking and approach to work.

Consider the standard phases of development and how the work that gets queued up using functional specialists and functional departments:

The larger the project, the bigger the queues of work, the greater the variability involved with that work, and the longer the cycle time of the system as a whole due to hand-offs of these large batches of work. There is also overhead required to plan and coordinate work between functional areas and specialists.

The goal of a Lean and agile organization is to reap all of the benefits of productive, satisfying software development that delights the customer for the least amount of effort expended. We start by recognizing that software development is a complex, non-linear and collaborative endeavor and respond by:

Discarding approaches that create WIP queues and the bottlenecks.
Using cross-functional teams that deliver complete features (business analysis, programming, and testing) without handing off work to other groups.
Applying practices such as pair programing and test-driven development to eliminate queues and streamline delivery by moving from linear to parallel development.
Continuously improving by being open-minded, inquisitive and continually learning and evolving.

This means that Scrum teams should not be approaching Sprints with a mindset that they are a series of mini-waterfall projects. Teams should be focused on the outcome that the team as a whole is producing for the customer. They should be doing so by working together as a team, collectively understanding the business need, agreeing on the definition of done, and determining how to accomplish the work with the least amount of effort expended by the team as a whole. Agile development should be efficient and disciplined.

Another part of the bargain is that an autonomous team makes a commitment to deliver a certain amount of functionality in each Sprint. It’s a team commitment to deliver the Sprint content, and the daily standup is where individual make even smaller commitments to deliver in meaningful ways that contribute to the team’s commitment.

Yes, there will be times when commitments aren’t met. Individuals may take on something that is outside of their comfort zone and stretches them. Likewise, this can occur at the team level as well, and a team can fail to meet its Sprint commitment. This is not a bad thing as people and teams should be pushing the envelope; and if they are, there will be misses every once in a while.

However, there are times when teams miss when they shouldn’t. I’ve seen problems because teams actually fail to manage their work. Two major areas where teams miss on managing are in planning and at the daily standup.

Planning. Teams should not accept poorly-prepared, un-groomed User Stories into a Sprint from the Product Owner. User Stories should be clear and include the “so that” portion to explain the business benefit to the team. The User Stories should also have clear acceptance criteria. User Stories are the team’s connection to the business and teams members need clarity about the team’ work, why it is important, and the criteria to judge when work will be considered done. Ambiguity with User Stories is a productivity-killer.

Daily Standup. I’ve seen people report on a task that is “taking longer than expected,” but the team takes no action. They let a high-priority issue continue to bog someone down without addressing the problem by swarming or at least having someone else assist in getting the task completed.

There are reasons that this occurs. Sometimes people want to hang onto work because they feel that it will reflect poorly on them if they don’t complete the task. This is where it is important to stress the team over the individual, and that collaboration is valued because it improves throughput. I’ve seen many situations where teams are failing to collaborate effectively, leading to lost time and aggravation that could have been avoided.

Sometimes people hesitate to speak up because they are afraid of confrontation – either because they are personally uncomfortable with raising concerns or they are afraid of the reaction that they will get. I devised the Elevator Story as a signal for the team to take action as a matter of policy to help address this issue.

Another productivity issue arises when people treat the daily standup meeting as a status meeting. The daily standup should be more than that. In short, standups are an opportunity…

To identify where knowledge and experience can be shared.
To identify impediments.
For each team member to make a commitment.
For the team to monitor its progress (towards its Sprint commitment) as a whole.

Another problem area deals with the boundaries and roles of Scrum. More on this in my next post.

Improve the Flow, Don’t Interrupt It

noreply@blogger.com (Dave Moran) — Tue, 24 Apr 2012 10:00:00 +0000

Agile development teams exist for the most part in non-agile organizations, and all too often there are too few who understand the implications of this and how well-intended actions actually work against the mindset and techniques of agile development. This can lead to a watering-down of agile (Waterfall/Scrum hybrids come to mind) and a reduction in the benefits obtained as a result.

From a management perspective, agile development should not just about autonomous teams doing their “thing” independently. Those autonomous still need management support – but in a different way. Autonomous teams should be focusing on improving the flow of value to the customer and you as a manager should be supporting those who have direct responsibility for that delivery.

Agile development seeks to eliminate or reduce overhead while using tools and techniques that improve – or at least maintain – professional discipline to drive long-term productivity gains. Agile teams need to work be “in the flow” as much as possible to improve productivity, taking input from customers and internal stakeholders and converting that input into a valuable outcome for the least amount of effort expended. As a manager you must guard against doing two things: interrupting the flow and impeding the flow.

Flow is interrupted when requests (demands) are made to support a separate flow of information and control to the rest of the non-agile organization:

Most of the time these are well-intentioned requests, but it places a counterproductive burden on the team to contend with these reporting and control mechanisms because the information being requested doesn’t contribute to the team’s output. It is a separate output that the team must produce to satisfy the desires of others elsewhere in the organization.

A variation of this is when flow is impeded, such as when a manager decides that since autonomous teams have more responsibility for their work, they can “take on” some of the work of the manager (or some other above-the-flow work):

This work – particularly if it is expected to be performed regularly – will act to continually constrain the output of the team.

Working above the flow is resource-intensive. We are imposing a burden by interrupting employees’ work to support a separate flow of information and control or by pushing existing, above-the-flow work onto the teams. Managers should be watching for and finding ways to keep these non-agile demands off of the team’s shoulders as much as possible, or at least reducing the burden so that the team can focus on improving the flow of value to the customer.

In this new agile world, managers need to add value to those who are now the ones responsible for delivering to the customer. Ask your teams if you are adding value – without being a burden. You may not like the answer, but if you are a burden, start looking for ways to change how you operate. A big change could be that you need to move from “managing” people to helping people manage themselves and the business.

Transitioning to autonomy is not smooth an easy; you will find that autonomous teams need both information and guidance. They will need to understand the customers and the business more deeply than they ever have before. They will also need to understand certain business constraints that you are operating under, budgets being a glaring example.

You can provide a lot of great information and guidance. It’s a process where everyone is accountable for the work being performed, and that you are all working together to produce valuable outcomes for the customer.

A Quick Example on How Going Slower is Faster

noreply@blogger.com (Dave Moran) — Fri, 20 Apr 2012 09:50:00 +0000

If you’ve ever been challenged to explain why you should consider adopting agile development, one good reason is that agile development – executed properly – focuses on all aspects of software development, from delivering value to technical excellence. This includes performing work that too often gets short-changed under intense schedule pressure: refactoring.

(This is an admittedly simple example, but it illustrates how focusing on feature delivery at the expense of looking at the big picture can hurt you in the long run.)

Let’s say that you are in a race. Both you and a competitor are vying to dominate a market with similar applications, and you are both starting from scratch. You are an agile development shop and your competitor isn’t; for them, cranking out the features is everything.

The picture below shows that your competitor establishes an early lead…

Your features take longer to deliver because you are paying attention to the complete picture. For you, quality is more than a defect count; it is the state of the software design and craftsmanship. You’re in this for the long haul, so you will be slower on a feature-by-feature basis because you are taking the time to refactor the code to keep it clean and manageable. And that is your secret weapon.

As time marches on, chinks in your competitor’s armor begin to show. Their code base is becoming unwieldy, and it is taking them longer and longer to produce features. You, on the other hand, are maintaining a regular cadence:

You are catching up and overtaking your competitor. But it’s still a close race. And then comes the big day. Your competitor hits the wall. They need to stop and re-write their system because they can’t add another feature. They’ve created a mess while you’ve been able to reduce the time is takes to deliver features because you’ve been steadily learning and improving. You’ve been eliminating overhead and working in new ways that accelerate the flow of value to your customers:

Suddenly, or so it appears, you’re able to streak far ahead of your competition, and you are even stealing customers away from your competition because the quality of your software is superior. Not a bad position to be in!

Let’s go back in time for a moment. What if your competition – recognizing that you are onto a good thing – introduces agile development during their product life cycle? Can they begin competing with you head-to-head?

No, they can’t magically get onto the same track that you are… Not yet. Their objective is to avoid hitting the wall. They have some debt to pay down first, like refactoring/redesigning the critical pieces of their code base at the very least. The bad news for them is that despite the length of time and pain they are experiencing in delivering features now, they need to spend even more time delivering features – if they want to prevent a worse experience from happening later.

Agile development isn’t a silver bullet, but it does focus your attention on the full picture. It’s a disciplined approach to delivering software designed to keep you and your software viable in the long term.

Don’t Hit the (Software) Wall!

noreply@blogger.com (Dave Moran) — Tue, 17 Apr 2012 10:00:00 +0000

Since the Boston Marathon was run yesterday, I thought this would be an appropriate metaphor.

Imagine running a 26.2 mile race… It’s a long race, but you’re prepared. You’ve run 20 miles every Sunday along with hill workouts and a variety of other distances during the rest of each week to be in the best shape possible. You start the race a little faster than you anticipated based on your split, but you shrug it off. You feel comfortable, so you keep going. You even ignore the early water stations. It’s a crisp, fall day, so heat is not a factor. Everything is in place for a great run.

Almost. The events described above were real. They happened do me. And I should have done things differently. I should have backed off my early pace when I got my split. I should have been taking in water. But when you are young and stupid (I was 20 years old at the time)…

I hit the wall. I started feeling odd at 18 miles, and by mile 20 I was done. The loss of energy and fatigue was sudden, and I had NOTHING left. I walked the remaining 6 miles, trying to find the strength to run every now and then, but I couldn’t. I finished in the middle of the pack, disappointed that I had run myself into the ground. I knew better, but in the moment of the race I thrust common sense aside and went for it.

Despite knowing better, organizations routinely run into the software wall all the time. We’re guilty of approaching work in the same way that has proven not work more often than it does, but expecting a different result.

We start out great. We feel good. Our emphasis is on “productivity,” measured by how fast we can crank out features. Early on, we meet our schedule. Our estimates may have been off, but this is a critical project (aren’t they all?), so management decrees that the team must put in overtime to compensate. This position is justified because the team isn’t meeting its commitment, right?

The problem is, overtime starts taking its toll. A week or two of overtime to get over a hump is one thing, but continual overtime coupled with strong schedule pressure starts driving behaviors that can kill you later. And it won’t be obvious, not at first. But the problems will sneak up on you.

Studies have demonstrated that projects with aggressive schedules and overtime have significantly more defects than other, more sustainable projects. (Check out the paper, Impact of Overtime and Stress on Software Quality by Balaji Akula & James Cusick.)

The danger for software projects lies deeper than the defect counts. There’s more to it than tired people making simple mistakes. Demands of continual overtime for weeks on end, plus relentless schedule pressure create compromises that shouldn’t exist.

Developers get too busy to conduct design or code reviews, or to refactor code when they should. If its 2:00 am and you’re faced with checking in code now so that you can get some sleep before starting on that next feature first thing in the morning or unit testing it a little more, or refactoring the code like you know that you should, what call are you going to make?

Code review at 2:00 am? Not a chance. Code review the next day? Not likely either, the schedule doesn’t permit it. Developers start hoping that they can “come back later to clean up the code.” The big danger is that code craftsmanship takes a back seat, which does not reveal itself as a problem until later in the project. But you will get warning signs.

One is that features will start taking even longer to add because the code base is becoming more complex – and unmanageable. And when one feature is updated, one or two other things break. As defects increase, even more time is diverted away from adding features because developers need to fix more and more problems. And the schedule starts to slide out even further.

Eventually you manage to deliver (most likely not when you thought you would), but the system has become more complicated than it should. If you leave things as they are, features take more time than they should to add, and you’ll always be faced with quality issues. If this goes unchecked, you will hit the wall:

The wall that you hit is the developers telling you – after asking them to add a new feature or two – that, “We can’t add any more features until we rewrite the entire system.” Hitting the wall hurts.

Next post, I’ll illustrate how agile development is a “go slower to go faster” approach that prevents us from hitting the wall.

Being Agile is Being Efficient and Disciplined

noreply@blogger.com (Dave Moran) — Fri, 13 Apr 2012 14:13:00 +0000

Is agile development chaotic and undisciplined, as some would assert? It shouldn’t be. However, using frameworks and practices don’t make you agile in and of themselves. They support agility, provided that you have the right mindset and approach to your work as you make use of them.

I’ll examine the following (briefly) in this post:

Scrum
Test-Driven Development
Pair Programming

A huge change with agile development is that teams are self-directed. Scrum is a great framework for teams to use to manage their work, provided that teams genuinely collaborate and actively manage their work. This means more than adopting the practices, vocabulary, and artifacts of Scrum. “Doing Scrum” without an agile mindset is also known as Cargo Cult Scrum, which is the mistaken notion that ritualistic actions and artifacts will provide magical benefits. Trust me, magic is not going to happen all by itself!

The goal is to improve productivity through collaboration, and for a team to coordinate its work without the need of oversight and direction from others. Agile team members don’t maintain strict functional roles and “hand off” work to one another or to another group, their emphasis is on delivering complete features as a team. The objective is to replace these hand-offs with people who are combining their efforts by interacting, sharing knowledge, managing their work and dealing issues together to produce a valuable (to the customer and the organization) outcome.

Good teams also make use of practices such as Test-Driven Development and pair programming that are designed to support agility, allowing them to maintain engineering discipline while streamlining the work.

Test-Driven Development (TDD) is about creating an automated unit test before the code is written. This changes the order of the traditional approach to work, with the goal of improving our work and making sure that we discipline ourselves for being productive over the long haul, without making short-sighted, short-term “productivity” sacrifices.

TDD enforces the discipline of creating automated unit tests on both the developer and any manager who might be inclined to push for shipping a feature now, sacrificing the creation of automated unit tests that are typically one of the long-term quality objectives many organizations have. And we need automated unit tests! They enables us to refactor the code with confidence, supporting the ability to continually and productively evolve and improve the design as we move forward.

Notice that I didn’t say TDD drives design, but rather that automated unit tests supports our ability to evolve and improve the design – something else that we need to do with agile development. It’s part of our overall commitment to quality and technical excellence.

Interestingly enough, while TDD doesn’t drive design, it does help to enhance it. The act of writing a test first forces the developer(s) to consider how the code will be called, and as a result the interfaces become a little more understandable. As a practice TDD also can improve the testability of the code because developers are writing tests beforehand, not after, and the goal is to create automated tests that cover the code as completely as possible.

For these reasons, Test-Driven Development is superior to what Jeff Langr referred to as Test-After Development, or TAD – as in a TAD too late in one of his 2008 blog posts.

Of course, TDD alone won’t solve all of your problems. Good design is important to the long-term viability of any software product. Good software design contributes to having fewer defects to contend with along with allowing new features to be added in reasonable time frames. I’ve argued that source code should be treated as an asset, not a liability (and I acknowledge that there are those who will disagree with me).

I readily agree that poorly-designed code is a liability because the level of difficulty in updating poorly designed code with new features can range from difficult to impossible. Poorly-designed code raises the bar in terms of the time, effort and level of concentration required to update it. And it usually requires a lot of regression testing to make sure that “unrelated” features weren’t dinged in the process.

Pair programming can help here. Pair programming should strengthen the design because two developers are discussing the current code base and what needs to change to support a new feature. You should seek to accomplish a combination of a design/design review along with a code review as a benefit with pair programming, with less aggregate time spent by performing those activities separately.

Pair programming has other benefits as well. My top five benefits of pair programming:

Improves design quality.
Reduces defects.
Accelerates problem-solving.
Broadens the understanding of the code base.
Increases job satisfaction.

I’ve covered Scrum, Test-Driven Development and pair programming as they relate to agile development. You can use any of these to obtain an incremental improvement with whatever approach to software development that you are using today, without question.

From an agile context, it pays to look a little deeper, to understand how you can eliminate or reduce work in process queues, to collaborate or apply techniques that reduce overhead and maintain or improve your overall professional discipline and achieve long-term productivity gains. That’s what being Lean and agile is all about.

Software Development Workflow Shouldn't Mirror its Phases

noreply@blogger.com (Dave Moran) — Wed, 11 Apr 2012 10:30:00 +0000

(My apologies for posting a day late, but I’m in one of those cycles where I’m generating content just-in-time instead of having a good backlog ready. I paid for it this week, as I ended up very sick Monday evening and wasn’t able to make a Tuesday post.)

In the future, we won’t need to program computers. They will program themselves to perform whatever tasks we ask them to perform. Until that day arrives, we’re faced with doing things ourselves. So for now, we need to generate value by flowing through the standard development phases as quickly and easily as possible. With agile development we target delivering potentially shippable software at the end of every sprint, but NOT by working in a linear fashion:

It’s tempting to reduce work to its constituent parts and have specialists complete each phase in strict, gated phases where we sign off on the work before beginning on the next phase. We have evidence to support this approach, including studies that show how the relative cost to find and fix defects increases substantially at every phase.

Other studies confirm that there is value in getting things right in each phase, and to be productive we should be doing things like:

Understanding and verifying the requirements because this has been proven to reduce defects and prevent costly rework later.
Creating good designs and conducting design reviews because good design not only reduces the number of defects in a system, good design allows us to add new features in reasonable time frames.
Conducting code reviews because inspections have proven to reduce defects.
Creating a suite of automated unit tests with excellent code coverage that enable us to refactor the code with confidence, supporting the ability to continually and productively evolve and improve the design.

While a linear model with well-defined phases and specialists to perform that work makes sense to us, it is actually counter-productive in actual practice.

A classic example of a problem with functional specialization and functional departments working in isolation shows up when Quality Assurance testers raise a flag about a feature delivered by development that is more than just a bug, but a problem where the QA group had a very different interpretation of the feature than development did. And now development wants QA to test what they built, and QA wants development to change the feature to conform to what they expected to test – and someone else needs to come in and work through what should have been done in the first place. (It seems like a long time ago, in a galaxy far, far away… but I have seen this happen.)

Granted, teams should be communicating and sharing information enough to avoid this problem, but functional hand-offs introduce bottlenecks, creates overhead and inefficiencies that we want to avoid because we aren’t producing the greatest output for the smallest effort as Peter Drucker advised us to do many years ago.

Another reality is that when the actual work is performed, things get a little messier. For one thing, we find that we need to iterate:

Why? Because despite our careful attention to detail, there will always be questions and issues that surface as we translate the “what” into the “how” because the work is complex in nature. We need UI designers, database analysts, developers, testers, business analysts and the actual business users to collectively shape the outcome.

Successful software development is a complex, non-linear, and collaborative endeavor, and applying the principles of Lean and agile help us to obtain all of the desired benefits with the minimal amount of overhead. It’s the combination of the right mindset, approach, tools and techniques that achieve this. And it is a disciplined approach. I’ll cover more in my next post.

Adapt and Improve Your Way Into Being a Competitive Force

noreply@blogger.com (Dave Moran) — Fri, 06 Apr 2012 10:00:00 +0000

As part of my Maine Agile User Group talk this week, I referenced a quote from management guru Peter Drucker that you don’t typically see or hear:

“Productivity means the balance between all factors of production that will give the greatest output for the smallest effort. This is quite a different thing from productivity per worker or per hour of work…”

This quote comes from his book, The Practice of Management, originally published in 1954. Unfortunately, another one of his quotes, “what gets measured gets managed,” is used and abused all too regularly.

As you can glean from the second sentence of Drucker’s productivity quote above, he was cautioning us about emphasizing the wrong things – and as the Principle of Suboptimization tells us – optimizing each part independently will not lead to an overall system optimization. In fact, it can worsen it. We need to be very careful about what we’re measuring and what behaviors we are driving with those measurements.

What I really like about the quote is the first sentence and how it directly applies to what we’re trying to accomplish with Lean and agile thinking: generating the greatest – and most valuable – output for the least amount of effort. It served as the cornerstone for my talk about being agile, the mindset and approach that we need to take to our work to reduce or eliminate queues of work and any potential for bottlenecks.

It was all about approaching work differently, striving to improve both the people and the system. Since I had books on hand as giveaways, I thought it would be great to quote material from the books. A couple of quotes that I considered relevant to adapting and improvement were:

“Agility is a quality of the organization and its people to be adaptive, responsive, continually learning and evolving.“ -- Scaling Lean & Agile Development:

And…

“The primary task of Toyota’s managers and leaders is not to focus exclusively on improvement, but on increasing the improvement capability of people.” -- Toyota Kata:

Agile development is frequently characterized as being able to adapt to changing software requirements, but we should set our sights higher. Change can mean improving at a faster rate, not just adapting to changing software requirements, and being able to do both will make you a powerful force to contend with.

We’ve Been Approaching Things in the Wrong Way

noreply@blogger.com (Dave Moran) — Tue, 03 Apr 2012 10:00:00 +0000

Agile development is all about using multi-disciplinary teams to continuously deliver working software in the form of business features at the end of every sprint or iteration. This means prioritized features, not horizontal architectural layers. By that I mean that we don't build out all of the layers up front in one shot, speculating on what we might need to have in place to support future business features. We design and build what is required for the features that we are working on today.

Likewise, the merits of the empowerment model espoused by agile development have been known for some time in the business world, albeit largely ignored. Most organizations today strive for central control and compliance, whereas an effective empowerment-oriented management model assumes that those on the front line can not only call their own shots effectively, but are better able to respond more rapidly to changing competitive conditions.

The right management model requires that front-line teams have autonomy and critical information available to them to make effective decisions. There is a need to invert the organizational pyramid – or at least tip it on its side – so that business units who are focused on profitably serving and satisfying customers’ needs are being informed and supported by a leaner organization that is not imposing onerous reporting and control mechanisms on the rest of the organization.

If you compare and contrast our traditional approaches to software development and managing organizations, we’ve managed to get things backwards.

Our traditional way of working is to build horizontal layers of software and work in hierarchical, vertical organizations:

When we should be building vertical slices of functionality and working laterally as an organization:

Leadership Agility: Transforming Problems into Results

noreply@blogger.com (Dave Moran) — Fri, 30 Mar 2012 10:00:00 +0000

My last post discussed reflective action from the book, Leadership Agility by William B. Joiner and Stephen A. Josephs. Reflective action is a leadership agility skill that guides you towards making better decisions, engaging in action, and then evaluating – reflecting – on what you’ve learned so that you develop as a leader.

As the book points out, if you are leading in a rapidly changing, complex business environment, you will be facing ill-structured problems. A key challenge for leaders in these situations is that solutions to these problems aren’t predefined, nor will they have one right answer. You will be working with incomplete information and evaluating a number of plausible solutions that will require what the authors called creative agility.

Creative agility is a combination of critical thinking skills and breakthrough thinking that generate “uniquely appropriate responses that transform these ill-structured problems into desired results.” Your creative agility is supported by two capacities:

CONNECTIVE AWARENESS: The ability to hold various ideas and experiences in mind, compare and contrast them, and make meaningful connections between them.

REFLECTIVE JUDGMENT. This capacity refers to the way you determine what’s true and what is the best course of action for solving ill-structured problems – and to the way you justify these views to yourself and to others.

These capacities vary, depending upon your level of leadership development (if they exist at all). The book explores five levels of leadership and how these two capacities are – or aren’t – part of leader’s repertoire:

EXPERT LEVEL: As an expert, you solve key problems. You treat problems as if the right solution had already been determined, either by senior management or technical or functional training. You analyze a situation and use your own judgment to make a decision.

ACHIEVER LEVEL: As an achiever, you accomplish desired outcomes. You have a greater appreciation of the ill-structured nature of business and organizational problems and you want to make sure that your diagnoses are consistent with the available evidence. You want to consider any data that will help you, but once you arrive at a position that seems consistent with the available evidence, you find it very difficult to seriously consider alternative interpretations of the same evidence.

CATALYST-LEVEL: As a catalyst, you mobilize breakout endeavors. You are capable of creating new contexts where people can tap into their creative potential by participating in the development of solutions that benefit multiple stakeholders. You seek to provide more meaningful and satisfying experiences that enable the sustained achievement of desired outcomes. You have a well-developed reflective capacity with a heightened interest in the relationship between experience and reflection, but your reflections on your experience don't take place on the spot. However, you are now able to make adjustments that you wouldn't have formally made.

CO-CREATOR LEVEL: As a co-creator, you realize shared purposes. You view all organizational processes and results as being created by many people working together simultaneously, with your interests focused on creating work environments that emphasize shared responsibility. You have an understanding and appreciation for frames of reference that may differ from your own. You look beyond – without ignoring – doing what the company needs to accomplish to ask what contributions the company can make – through its people – to the world through a deep collaboration with others.

SYNERGIST LEVEL: As a synergist, you evoke unexpected possibilities. You have a “power of presence” that deeply attunes you to people, groups, and organizations. Your skills are more blended and available when you need them, in the moment or through more deliberate thought. You are able to sense subtle “energetic dynamics” that would have escaped your awareness at earlier levels. You remain focused on the common good while holding in mind multiple and conflicting stakeholder views and interests in an accurate, yet empathetic way. You are driven from a desire to engage with life in all its fullness and to be of real benefit to others.

I’m not doing the book justice with a short summary like this, but Leadership Agility does a great job of exploring the five levels of leadership and how they differ. The “Five Eds” in Chapter Two uses a common scenario of a new CEO being given a mandate to restore profitability within two years and reclaim market leadership of a firm within three to five years.

In a dinner conversation that is replayed for each leadership agility level, Ed talks about how he views the current situation, what he sees as problems, and how he plans to go about meeting his mandate. The differences are remarkable, and you can’t help but want to work for the leader at the higher levels. You feel a certain pull that isn’t evident in the earlier levels.

Leadership Agility takes you through key steps in leadership development along with the ins and outs of each level so that you as a leader can reflect on where you are today and what you can and should aspire to be tomorrow. I highly recommend this book!

Develop Your Agile Leadership Skills with Reflective Action

noreply@blogger.com (Dave Moran) — Tue, 27 Mar 2012 10:00:00 +0000

In today’s turbulent business climate, leaders are facing complex problems. A leader’s ability to successfully navigate continually changing, uncertain waters requires continual reflection and improvement. A great resource for developing your leadership capability can be found in the book, Leadership Agility by William B. Joiner and Stephen A. Josephs.

In their book, Joiner and Josephs state that, “At its core, leadership agility is a process of stepping back from your current focus in a way that allows you to make wiser decisions and then fully engage in what needs to be done next. We call this core process reflective action. Reflective action is both the essence of leadership agility and the best way to develop it.”

And just how is reflective action both an essence of leadership agility and the best way to develop it? The paradox is easily resolved once you understand what it is.

First, pick one issue, but before you jump to a solution, make sure that you fully understand the issue. The next step – and one that is commonly overlooked according to Joiner and Josephs – is to clarify your desired outcome. Then clarify what you need to do to achieve your desired outcome. And finally, after you have taken action, reflect and learn from what happened.

The process sounds very agile to me! And as you may have surmised, reflective action can be something that is rapid and intuitive, like when you are in the midst of a conversation, or it can be more deliberate and systematic, such as taking time to thought in developing a new business strategy.

It does take a willingness to look honestly at yourself, along with a little curiosity, courage, and self-confidence to experiment with new behaviors. The good news is that you can make reflection action a daily practice and a means of continually improving as a leader.

Being Agile: Preparing a User Group Talk

noreply@blogger.com (Dave Moran) — Fri, 23 Mar 2012 10:00:00 +0000

I’m preparing for a talk for our next Maine Agile User Group meeting on April 3rd, and I’ve decided that my topic will be: Being Agile versus Doing Agile. My goal is to convey an understanding of what it means to be truly agile. Early on, one of my slides asks:

Is Scrum agile?
Is TDD agile?

Friend and colleague Paul Corriveau recently answered this question in a blog post, Scrum Is Not Agile. I’ve had many conversations with Paul about agile, and we’re always looking to learn more and apply that learning, so it is no surprise to me that his post is consistent with my thinking. As Paul points out, building good software takes more than “process magic.” It takes effort and discipline to change your thinking and your approach to work in order to improve from where you are today.

Scrum (or agile for that matter) is not a silver bullet any more than OOP or any other promising technology or approach has been in the past. Frameworks and practices are tools that support agility, but they don’t make you agile and you won’t reap magical benefits without putting in some real work. That said, you can achieve some incremental benefits by implementing practices or using a framework, but most companies today want a lot more. And that’s where being truly agile comes into play.

Some people challenge that agile development isn't something real because it defies being described in a sentence or two, at least in a way that provides true meaning. I’ve tried, but I never liked the results. You end up with either a brief description of the mechanics, a description of the potential benefits, or vague statements like, “It’s a framework” or “It’s a mindset.” Or a combination of all of these.

These days, my response is that if we didn’t already “understand” the traditional way of managing and working, we couldn’t succinctly describe it in a meaningful way, either. Imagine trying to explain how companies are run today and how non-agile software projects are managed to an alien visitor from another planet – who had no point of reference to any of our ways of working. You couldn’t explain that in a couple of sentences, either.

The context of my presentation will be to talk about the nature of software development and its inherent challenges and how being truly agile in your thinking and approach can help overcome these challenges. Towards the end I’ve managed to sprinkle in some concerns I have about the need for organizational agility and how agile development teams are challenged as a consequence of being surrounded by a non-agile organization.

I’m still tweaking my slide deck, but I’m looking forward to the meeting and I hope that my talk can stimulate some great discussions!

Are You a True Servant Leader?

noreply@blogger.com (Dave Moran) — Tue, 20 Mar 2012 10:00:00 +0000

As a leader, are you adding value to your people? Without being a burden, that is?

In this age of autonomous, collaborative teams, true servant leaders need to ask themselves just that. At least as a starting point. I submit that the real answer to this question needs to come from those that you are serving, and not from within.

This question is important because the problem with the traditional, command-and-control model of management is that employees have to contend with overhead to provide a flow of information about what they are doing – and knowledge workers are the ones who know most about what they are dong – to others in management so that these managers can “direct” the employees more effectively.

And the overhead changes every time there is new leadership. Employees are continually contending with providing reports and information tailored to the preferred format of whoever is requiring the information. The unfortunate part about this is that too many management decisions are made with distorted information from offices or conference rooms that are at least once-removed from where the real action and day-to-day decisions are being made.

Speaking of distortion, there are also times when a form of a reality distortion field is involved; this was not confined to Steve Jobs. He excelled at it, but more than a few managers have the capacity of bending reality to their perspective as opposed to really hearing the employee’s take on the subject and working constructively with the employee to solve the real problem at hand.

When an employee enters a management reality distortion field like this, the positional authority of the manager can make for both an uncomfortable and less than helpful dialog that leaves the employee worse off than before, because a) the employee must still take action to satisfy the actual needs of the situation on the ground, and b) take additional action to satisfy the needs of management.

True servant leadership in a lean and agile context is a “go and see” approach – in real time, not through reports and not by summoning others to your office. An agile servant-leader adds value to those responsible for delivering to the customer without adding overhead. The focus is on improving the flow of value to the customer and supporting those who have direct responsibility for that delivery.

Is the Scrum Framework Lacking?

noreply@blogger.com (Dave Moran) — Fri, 16 Mar 2012 10:00:00 +0000

What does it take to succeed with agile? When we first started with agile development, we a sent a couple of people to an agile conference, and they returned with advice from others that we should expect to take about “two years to get it right.” We shook our heads and wondered why. After all, we had selected Scrum as our framework, and it seemed simple enough.

As we discovered, there is some real change lurking beneath that simplicity. The current Scrum Guide states that Scrum is:

Lightweight
Simple to understand
Extremely difficult to master

Adopting agile means more than adopting a simple framework, it means adopting a different way of working and interacting that involves some very real change. It is the change that is difficult to master, not the framework.

The Scrum framework is carefully and thoughtfully constructed, providing well-defined roles, events, artifacts, and rules that serve a specific purpose and are essential to Scrum’s success. However, there is a critical difference between the February 2010 Scrum Guide and the July 2011 version of the Scrum Guide. In the July 2011 version, Jeff Sutherland and Ken Schwaber state that, “…we have attempted to remove techniques or best practices from the core of Scrum. These will vary based on circumstance. We will be starting a ‘Best Practices’ compendium to offer some of our experiences later.”

Jeff and Ken have kept the Scrum Guide focused on the framework itself, but as everyone experiences, teams need more guidance than what the framework has to offer. It is frustrating to make the same mistakes that others have made because the information was lacking up front. Having teams independently discover – or rediscover – techniques may help to cement learning, but in this information age that is an archaic approach.

I’m glad to see that Bruce Winegarden has taken up the charge to capture more explicit rules as he states in his recent post, Kick Start Scrum with Explicit Rules. I’ve observed Bruce in action as an agile coach, and teams that he has coached have certainly benefited from his advice. And I agree with his point that there is value in stating more explicit rules as a starting point – provided there is knowledge-sharing about why these rules exist in order to convey a full understanding of their purpose.

Change exists on many fronts in agile adoptions, like the mindset and behaviors of management and how work itself is approached, but being successful at a team level is a critical step to gaining acceptance at a broader level. I look forward to hearing more from Bruce and his thoughts on agile development!

If You Are Afraid of Losing Control, Try This Experiment…

noreply@blogger.com (Dave Moran) — Tue, 13 Mar 2012 10:00:00 +0000

As VersionOne’s State of Agile Development Survey reveals, a couple of the greater concerns about agile development are expressed as management concerns. Management opposition being one and a loss of management control the other concern.

Management that lacks prior experience with agile won’t be familiar with, nor comfortable with, the autonomy and the inherent trust that comes with autonomy. Unfortunately, both autonomy and trust are required to be truly agile. The challenge for management is that most companies recognize that they need greater engagement from their employees; they need people who will think and act with a greater understanding and ownership of their work.

The dilemma is that while adopting agile and its use of autonomous teams can help to create the very conditions that result in having more engaged employees, there is concern that, “It won’t work for us.” Is there a way to test the waters without making a leap of faith? One that allows you to directly witness the power of autonomy unleashed to its fullest potential, in the context of your own environment and people? You bet there is.

Try a FedEx Day using Atlassian’s model.

FedEx days have been billed as a fun way to drive innovation or “…a means to empower employees and boost their sense of autonomy,” as Six Feet Up’s Carol Ganz says in one of Atlassian’s case studies. But a FedEx Day can be a great learning tool for management as well, even if you don’t directly participate. Encourage and support your FedEx day and then watch your people.

We just held our second FedEx Day, and while we had some very different projects this time around, there was a great deal of consistency with one aspect to our first FedEx Day: the commitment, energy, passion, and collaboration that was a consequence of our self-organizing and totally autonomous teams was truly amazing.

FedEx Days unleash the incredible potential of your employees in a very demonstrable way. Properly run and supported (no guilt-trips about regular work being left undone, for example), a FedEx Day creates the exact conditions required for engagement and employee involvement with strategic thinking. The sparks of creative energy that get fanned into small fires – given the time constraint of delivering something overnight – will no doubt surprise and impress you. And you will have your evidence.

If you happen to observe a big difference between your FedEx Day and the day-to-day work, the next question you need to ask yourself is why you aren’t getting more out of your employees on non-FedEx Days. It can be a signal that maybe, just maybe, you need to adjust your leadership style.

And congratulations to the winning team!

The "We've Got Issues" team pose with their first-place trophy.

It’s Not About Efficiency, It’s About Resiliency

noreply@blogger.com (Dave Moran) — Fri, 09 Mar 2012 11:00:00 +0000

“Most white-collar workers wear white collars, but they’re still working in the factory. They push a pencil or process an application or type on a keyboard instead of operating a drill press. The work is planned, controlled, and measured. It’s factory work because you can optimize for productivity.” – Seth Godin, in Linchpin

Seth Godin is urging us to become indispensable, original thinkers; those who are difference-makers and not commoditized, low-paid workers who are easily replaced. A great many organizations deliberately plan for efficiency and reliability by breaking work into distinct, specialized pieces that can be performed routinely, but there is a downside to “optimizing for productivity” in this way.

For today’s post, I’ll point you towards my guest posts on VersionOne’s Agile Management Blog, where I discuss a significant benefit of being agile: Organizational resilience.

The Agile Resiliency Factor: Part 1 of 2
The Agile Resiliency Factor: Part 2 of 2

“In Agile We Trust”

noreply@blogger.com (Dave Moran) — Tue, 06 Mar 2012 11:00:00 +0000

Being an agile organization is a major cultural shift from the way many organizations manage today, which can be broadly summed up as being plan-driven by a centralized, command-and-control structure that relies on a heavy dose of reporting. And while this model works, it is proving cumbersome, costly, and unable to adapt quickly enough in today’s turbulent business climate.

It’s not uncommon to hear senior executives express deep concern about the lack of employee engagement (which collectively costs U.S. companies hundreds of billions annually in terms of lost productivity) and the need for commitment and results from people because “they are our greatest asset.” Yet companies continue to manage in ways that say, “I don’t trust you” to the very people on the front line who are responsible for – and should be trusted – to conduct business with and for a company’s customers.

While there are many who will assert that they are using a “trust, but verify” model, companies expend a great deal of time and effort in reporting and oversight that is geared towards compliance – along with imposing serious constraints on what those on the front line can and can’t do without centralized approval. Even with information systems designed to facilitate the approval process, it’s still a cumbersome, inflexible and slow system that siphons time and attention away from delighting the customer and maximizing the value that the entire organization brings to the customer.

Worse, some companies manage solely “by the numbers,” creating a “management by fear” climate in the name of driving accountability. Don’t make your numbers and you’re history…

While driving a profit is certainly important, agile organizations recognize that making your numbers isn’t everything. The financials are one measure of how delighted your customers are – because they are buying products and services from you – and they tell you how well (how profitably) you are delivering those goods and services. But it's the people who get you there and the processes and culture that drive a great deal of productive or unproductive behavior.

Being an agile organization (lean applies here as well) is all about removing the overhead and constraints associated with operating a business, not unlike what small businesses do when they start to grow. Small business owners don’t hire extra people to “manage” and control them as business takes off; they bring in extra help to deal with all the administrative overhead so that they can remain focused on the serving the customers.

An agile organization opens everything up, which involves a combination of transparency, honesty, and mutual trust. Agile organizations start by trusting that people want to do good work and delight the customer, giving the latitude and support to the people directly responsible for delivering that value. The role of senior executives shifts to one of partnering and coaching versus monitoring and controlling.

Agile organizations don’t use information systems to automate and make it easier to drive a centralized command-and-control structure; agile organizations concentrate on using information systems to inform the organization, to facilitate information-sharing and building a common understanding of the business and the customer base. They turn the entire organization on its head and eliminate the need to use – let alone automate – heavy-handed control mechanisms driven from a corporate center.

Agile organizations shift towards looking at the company’s operations in new ways. The goal is to streamline processes and eliminate waste, to find new ways of doing things and being more productive on a continual basis. Everyone is involved in thinking about the strategy of the company and in how to improve its operations. Anything that does not contribute to delivering value to the customer is called into question. Queues and bottlenecks are continually being examined and eliminated. The goal is to make every aspect of the business lightweight and fast, with an eye on delivering value to the customer at all times.

By removing the bureaucratic overhead and shifting responsibilities to those on the front line, a greater understanding of the business and engagement result. It also creates the ability to immediately adapt and respond to the changing needs of the customer and those challenges that always arise along the way. Sure, people have boundaries, but those boundaries are both clear and broad, but they are built on a foundation of trust that moves a company forward in all the ways most companies these days are only saying that they want to.

Strive for Excellence, not Perfection

noreply@blogger.com (Dave Moran) — Fri, 02 Mar 2012 11:00:00 +0000

Our mental models can get us into trouble. For example, managing very dynamic, highly variable efforts like software development though a series of crisp, well-defined, sequential phases seems to be very – to quote Mr. Spock – “logical.” Yet as many of us can attest, more often than not this logic breaks down rather quickly in actual practice.

The arguments for a sequential approach are sound, at least on the surface. You define your requirements, do your design, implement that design (code), and then verify (test) that everything is correct. Everything is in a nice neat, orderly, logical sequence of events.

What makes everything work well is the perfection of the outputs from each phase. The better execution you have in one phase leads to greater efficiency and effectiveness in downstream phases. In fact, studies have proven that finding and correcting problems (defects) increases significantly the deeper into the development phases you go:

What breaks down, and what can we do about it?

Software projects are the most unpredictable in the early stages of a project because there is a great deal of variability present in the early stages. How much, you ask? Let’s take a couple of statistics dealing with requirements, the very first phase:

Requirements defects in software projects account for approximately 50% of product defects.
The percentage of the re-work on software projects due to requirements defects is greater than 50%.

(Sources: Software Requirements 2 by Karl Wiegers and Code Complete by Steve McConnell)

That doesn’t sound too promising, does it? One thing that you don’t want – but can easily get with a sequential process – is that, “Now that I see it…” response when demonstrating the finished software. That means a change in requirements, after you’ve built the feature. And that is a very expensive way to build software.

Fortunately, variability does decrease, and Steve McConnell graphically represents how variability decreases over time with software projects with his Cone of Uncertainty (from his book Software Estimation):

As you can see, the cone is largest the earlier in the traditional project life cycle you are, but it narrows from uncertainty to certainty as different stages are reached – as those on the team learn more about the effort that they’re involved with. McConnell has observed that software projects typically reduce their variability at about 20 to 30 percent into the project because of the learning that takes place.

McConnell makes another vitally important about the cone of uncertainty. In an effort to obtain a reliable end date, a manager might ask, “What if we give an extra week to work on your estimate, can you refine it so that it contains less uncertainty?” Unfortunately, improving estimates requires working out the variability that drives the uncertainty, and this means performing the actual work of the project, so the answer is “no.”

If you can’t drive out variability without working on the project, you can try as hard as you like to be absolutely perfect early on, but you’re destined to fail. You have to go beyond the requirements phase and get into the actual work. Gaps will emerge as developers instruct a very literal computer just what it needs to do.

Even Agile development with its quick, iterative approach doesn’t completely solve the problem, either. After all, iterating is still a re-work strategy. But at least Agile development gets people working on a project very quickly, without wasting a lot of time with a Big Requirements Up Front and Big Design Up Front effort before people start getting really involved and learning what they truly need to know.

The lesson is simple: Don’t overinvest in seeking perfection – particularly in those early phases – that won’t be worth the paper that it is written on, particularly in the early stages. Seek excellence instead.

Excellence in software development execution starts with an acknowledgement that things can and will go wrong. The requirements might look right on paper, for example, and they may be “signed off” on as being correct. But they might be wrong for reasons that become apparent later.

I’m not making an excuse to be sloppy – excellence means being as crisp and clear as possible within reasonable time frames. But excellence is about all of those things that go into understanding software development and seeking to continuously improve. To look at how to improve in ways that I described in my last post, You Don’t “Do Agile.”

And excellence shouldn't be measured by who can write the longest requirements document, as Dan Naden just wrote about on VersionOne's Agile Management Blog. As Dan says, we should, "Deliver value in the most efficient way possible."

One way to achieve excellence – and to solve the requirements problem – is to invest in prototyping, following Marty Cagan's advice: “The majority of the product spec should be the high-fidelity prototype… I have long argued that requirements (functionality) and design (user experience design) are intertwined and should be done together.”

Seeking perfection can be very expensive and it can drive you nuts because perfection doesn't happen often with software projects. The pursuit of excellence, however, is a noble, satisfying, and rewarding experience.