Wednesday, August 29, 2012

A Taste of Lessons #10: Understanding Agile

Today’s taster from my new Lessons in Agile Management book comes from chapter 10 - Understanding Agile. The chapter threads together a series of articles from 2003 onwards that seek to put some underlying framework to Agile principles and values and to explain how Agile is differentiated from earlier 20th Century approaches to software development. As I explain in the chapter introduction, I’d argued at Agile 2008 that an underlying model for Agile was required - something more rigorous than the “Principles behind the Manifesto” - and that the Agile Alliance board had discussed it, decided it was important but no one was willing to commit to making it happen. As Dave Snowden has pointed out, an underlying model is required in order to scale concepts successfully. Chapter 10 brings together my own thoughts on an underlying model to help you understand Agile and hopefully from that understanding become more successful implementing it at scale. The extracted article is from February 2007 and includes from contemporary commentary…

Making Progress with Imperfect Information

Contemporary Commentary

My depth of understanding of Agile values, principles, and motivations continued to grow through the middle part of the last decade. While I’d identified high levels of social capital, or trust, as perhaps the true differentiator of the Agile era, I came to realize that there were some other dimensions. The one that had been hiding in plain sight, as a practice, became evident to me as a principle around the winter of 2007.

I’ve been re-evaluating my view on refactoring!

It’s interesting how your vantage point can color your view of something. My perspective on the Agile community and its practices has always been rooted in my experience with Feature-Driven Development and the Coad Method. When I spoke at USC back in 2004, I suggested that although Feature-Driven Development might never be seen as the most agile of Agile methods, it was probably the most Lean. I stand by this comment three years later. FDD is very Lean. All the waste is trimmed out. The Coad Method techniques deliver a precise definition of a domain that is loosely coupled and highly cohesive, while the Feature definition technique delivers fine-grained customer-valued units of work that exhibit very low degrees of variation in size and complexity. The batching technique of Chief Programmer Work Packages is very efficient and minimizes transaction costs associated with work-in-process. I could go on, but you get the point—FDD is Lean. The modeling, planning, and batching for design and build result in almost no need to refactor code on FDD projects. As a result, my book, Agile Management for Software Engineering, classified refactoring as rework, and labeled it as waste.

From my FDD vantage point, that might have been a fair assessment. However, now that I’m running a software-engineering organization, with which I inherited a waterfall process that runs through a series of narrow and specialized departments such as Business Analysis, Systems Analysis, Development, and Test, I’ve changed my opinion. From a new perspective, refactoring is clearly a very valuable process.

I believe that Alistair Cockburn’s paper from the ICAM 2005 InternationalConference on Agility will come to be seen as a seminal paper in Lean Software Engineering. In this paper, Cockburn explains that asking a non-bottleneck resource to do extra work to rework something does not cost anything extra, and it can create a desirable effect because it allows progress to be made and demonstrated sooner. Ergo, rework is not waste when performed by a non-bottleneck resource.

There have been many versions of the idea that perfect is the enemy of good enough. Its origins are perhaps traced to Voltaire, who said, “The best is the enemy of the good.” And it is this concept that refactoring (and Cockburn’s paper) embrace. He argues that it is better to make progress with imperfect information, and refactor later when better information is available, than to wait for better information before progressing.

Specifically, I am thinking that it is better for developers to start coding with imperfect analysis than to wait for a systems analyst to produce a “perfect” specification.

Contemporary Commentary

I’ve come to realize that this notion is at the heart of eXtreme Programming, and it was described in Kent Beck’s seminal book on the topic, Extreme Programming Explained—Embrace Change (Addison-Wesley, 2e, 2004). Beck refuted, though without any truly scientific study, Boehm’s finding from 1976 on cost of change. Boehm’s work and subsequent corroborating evidence suggested that late-breaking changes cost exponentially more. The Boehm evidence on the economics of software development favored the pursuit of perfect information early in the lifecycle. This ultimately led to the development of more and more analysis and design techniques that pursued greater and greater levels of information discovery earlier in the lifecycle. The core mistake is to assume that this is even possible. The nature of software development is too complex for this to work. What is required is to probe for more information with partial or approximate solutions, and implement a feedback loop so as to iteratively pursue the answer. Boehm’s later work on Spiral Model in the 1980s showed that he understood this. The rest of the industry did not. Ultimately, the pressure from heavyweight processes, laden with analysis and design techniques, was to provoke the Agile revolution in the late 1990s. So, while a true differentiator of Agile methods is their embracing of a high-trust culture—with all the benefits that delivers—the true essence of Agile is the concept of moving forward with imperfect information and being prepared to rework later. Rework wasn’t waste in the traditional twentieth-century quality-assurance movement’s understanding; rather, it was further information discovery based on feedback.

The developer can then refactor the code when the analyst makes a final version of the specification available. My reasoning is simple. The developer would otherwise be idle. (Not truly idle, as there is plenty of busy work available—grooming environments, training on new languages and APIs, and so forth, but idle in the sense that he or she is not adding value to the deliverable.) By definition, a resource (or station) with idle time is a not a bottleneck resource. It is, therefore, okay to ask a developer to perform refactoring. The refactoring cannot be classified as waste in a case like this.

We can think about this decision using real-option analysis. The option we are buying is to deliver the working code sooner. The cost of the option is the cost of having the developer start work before a final specification is ready. The risk (or uncertainty) attached to the option is the risk that the early, imperfect specification will be significantly different from the final specification, and that any rework will take longer than waiting to start coding on delivery of the final specification. Note that the rework may absorb all of the slack in the non-bottleneck resource, turning it into a bottleneck and delaying the whole project. This gives us a framework to decide whether starting early and refactoring is the correct decision, or whether waiting and coding for “right the first time” is the correct decision.

Tuesday, August 28, 2012

What Kanban Coaches Do, and Don’t Do

I’m realizing that predominantly Agile coaches/consultants have a lot of misunderstanding about what it takes to be a Kanban coach. Consequently, they believe that Kanban is just another method they can deploy using the same coaching/consulting techniques they use for Agile methods. This assumption would be wrong. Not just a little wrong - completely wrong! As a result of this assumption some Agile coaches wishing to offer Kanban as part of their services and as a tool in their toolbox, may be undervaluing the utility of attending my 3-day Advanced Kanban Masterclass for coaches, consultants and managers.

What’s more interesting is that I don’t observe the same bias in consultants from a different background such as CMMI, Six Sigma, Lean (manufacturing), Theory of Constraint, Program or Risk Management. They don’t arrive with the mindset that “Kanban is just another Agile method. So all I need to do is learn the mechanics and deploy it like Scrum or TDD.” This is good because you cannot (or at least, should not) deploy Kanban like Scrum or TDD.

So what exactly do Kanban coaches do, and more importantly what don’t they do?...

Stop Advocating! Stop Evangelizing! Observe Instead

Perhaps the biggest challenge teaching an Agile coach to be a Kanban consultant is to get them to stop advocating a position and stop evangelizing Agile methods and practices. At its worst Agile is a religion - a belief system with zealots who are beyond logical reasoning or debate. They have blind faith that Agile is better. Even worse is that they may believe that they have been sent to convert the heathen and turn them into true believers. These more extreme Agile coaches may never make the transition to coaching Kanban. They simply can’t let go and take a more neutral stance, by observing current processes and current challenges and recommending a appropriate course of action.

Kanban coaches don’t advocate or evangelize. They observe and advise.

There Is No Judgment in Kanban

A Kanban coach must never judge. The current situation is what it is and it got to be that way because of the current people, their circumstances and the demands of their customers. Wishing it were different is not useful. Criticizing because current practices are not aligned with a trendy modern approach or with a belief system is disrespectful.

Kanban consultants respect the current situation and do not pass judgment upon it.

Is Kanban Appropriate?

Good Kanban consultants make a situational assessment to establish whether Kanban is appropriate or not. We spend perhaps half a day of training on this topic. I’ve given key note speeches advising when Kanban might be appropriate. The summary is that kanban systems offer deferred commitment, control of variability in flow, elimination of over-burdening, reduction of multi- tasking, and better alignment with high level risk management decisions regarding allocation of supply against various competing demands. If any of these things are problems in the current process, such as committing too early and then failing to delilver against a promise, then a (virtual) kanban system might help.

The full Kanban Method uses virtual kanban systems and several other practices to create an evolutionary capability within an organization and promotes evolutionary change. This is useful in complex domain situations that are almost always present in knowledge work.

A good Kanban coach assesses whether Kanban is appropriate before recommending it! You don’t ‘sell’ an evolutionary approach to a revolutionary client. Situational awareness is a critical skill for Kanban coaches.

Kanban Should Be Like Water

Water flows around the rock. The rock is emotional resistance to change - change that will lead to better economic and social outcomes for all stakeholders and lead to better satisfaction all round. Kanban coaches learn how to anticipate emotional resistance - to identify the rocks before they design and deploy a kanban system process solution.

Kanban coaches avoid rocks initially! Where a rock cannot be avoided they design the kanban system to raise awareness and create emotional motivation for change. Water smooths out rocks over time. Good Kanban coaches know that it takes only one of them to change a lightbulb, but the lightbulb must really want to change. Creating the circumstances for self-motivated change is the work of great Kanban coaches.

(Virtual) Kanban Systems Design Is An Advanced Skill

Great Kanban coaches know they must not try to force change that will meet with resistance. They must avoid designing a (virtual) kanban system that fixes all the dynamic system problems they may have identified from initial observation. Perhaps the solution to over-burdening - introducing WIP limits - will meet with resistance? This resistance can be predicted by understanding the emotions of those involved - how such a change affects their self-image, self-esteem, ego, social status, or other psychological or sociological elements.

The art and science of great (virtual) kanban system design for knowledge work processes is knowing where to stop and knowing how to create a situation that will raise awareness and create motivation so that the next step can be taken.

Identifying Quality Kanban Consulting

It is for all these reasons that we teach an intensive 3-day Kanban coaching class that assumes the attendees already know all the material from the 2-day class and from the Kanban book. The 3-days are not a refresh on the 2-days plus an extra day, they are 3-days of learning new coaching skills.

Because Kanban coaching is such a special set of skills and so decidedly different from Agile coaching, Lean-Kanban University has created a professional designation, a trustmark, so that clients can identify those known to be good, trustworthy, competent Kanban coaches and consultants. For this reason the Kanban Coaching Professional (KCP) designation has been introduced and my 3-day Advanced Kanban Masterclass is the prescribed educational prerequisite for achieving KCP status.

P.S.

If you are interested in taking a 3-day Advanced Kanban Masterclass for coaches, consultants and managers leading Lean change, we list them on our Events page. You will be very welcome.

Accredited Kanban for IT Ops and DevOps - Seattle - Nov 6-7

with Dominica DeGrandis (instructor)

Kanban for DevOps seeks to improve interactions and dependencies between teams and departments.  From business requests to IT delivery, we discover how to improve work flow across different functional teams. Devops is about respect, cooperation and trust among individual practitioners and leadership.  With Kanban, we look at how using a service-delivery approach can help unify teams and promote cross-functional collaboration.

This 2-day workshop introduces the Kanban Method and its associated principles and core practices. Exercizes are designed to bring visibility to the problems in need of improvements.

We begin by studying the demand on your team, department or organization and learn how to gather data to understand the capability of your system and how it operates.

Discussions and interactive exercises on the Kanban Method will address the following topics:

- Specialization and shared services
- Dependencies between teams
- Variable task size
- Interrupt driven work

Participants will analyze and design a Kanban system intended for implementation upon return to the organization. 

We will also look at how to manage risks related to the increasing complexity around software delivery and support.  Attendees play the “Kanban for DevOps” version of the GetKanban game. 

Class Schedule

Based on David J. Anderson’s book “Kanban - Successful Evolutionary Change for Your Technology Business”, attendees of the class will receive a copy of the book.

What others are saying about this training

“What a worthwhile use of my time! It is rare that I walk away from professional training feeling so inspired and fulfilled and wanting to tell everyone about it!!” - Jane Despas, Cloud Services, Cisco

“Dominica,  Thank you for the great kanban for devops training.  I learned how to use kanban to illustrate my work.”  Alex Honor, Co-founder, DTO Solutions

“I was in your Kanban training earlier this week – thank you. I got a ton of useful information out of it and it has definitely prompted us to think about how we want to use one for our team.” - Kate Compton, IT Manager, R.E.I.

“The class was excellent. The minute our kanban board went up, everyone started asking questions and getting involved when they never had before.  I am seeing managers take actions to investigate issues without having to escalate – a huge plus. The conversations alone are worth the effort!”
Betsy Hearnsberger,  Release Manager, Cisco

Is this for you?

This training provides a useful perspective for improving work done on the periphery of software development.  If ever-more frequent deliveries from software development are increasing pressure on your teams and creating bottlenecks in the delivery process, look at Kanban to extend agility and balance to IT services and operations teams.  From Data Administrative Services to Deployment & Release Managers to Help Desk, this class covers beginning to intermediate level material.

Register today!

Only $1200 per person

Pre-requisites:

There are no formal pre-requisites, other than some suggested reading prior to attendance.

Group Discounts

A 4th person may attend for free with 3 registrations. Contact .(JavaScript must be enabled to view this email address) for questions on group rates or for payment options other than Google checkout.

Cancellation Policy – Please Note:

Substitutions are accepted at any time. Cancellations must be notified by email and refunds will be provided according to the following:
More than 10 days prior = 80% of course fee
5 to 10 days prior = 50% of course fee
Less than 5 days = no refund provided
DJAA reserves the right to postpone or cancel this event if there are insufficient registrations or if presenters are unable to attend due to illness. If necessary, you will be notified no later than 7 days prior to the event and all registration payments will be refunded promptly.  If circumstances require, presenters may be substituted for alternative qualified presenters with equivalent experience.

About the presenter

Dominica DeGrandis specializes in Kanban for IT Services and Operations with teams interacting with software development. She spent her first 15 years in software engineering deeply embedded in development teams performing builds, deployments and environment maintenance. She has worked in organizations of all sizes, from the US Army, Boeing, and AT&T to small start-ups. Dominica first worked for David J. Anderson at Corbis in 2006 where she helped deliver the first implementation of Kanban for software engineering in the US. Adept at leading teams performing Configuration Management and Release Management, Dominica found a passion for improving the way development and operations teams work together.  Dominica holds a BS in Information Computer Sciences from the University of Hawaii. She can be reached at .(JavaScript must be enabled to view this email address).  Follow her on twitter at @dominicad.

Location:

Seattle, WA, USA

Venue:

University of Washington, Foster School of Business
Eastside Executive Center
10220 NE Points Dr, Suite 100
Kirkland, WA 98033

http://www.foster.washington.edu/academic/tmmba/Pages/ContactUs.aspx

Monday, August 27, 2012

A Taste of Lessons #9: On Human Resources

Chapter 9 of Lessons in Agile Management collects a series of six longer articles I wrote expressing my managerial frustration with the policies imposed upon us managers by human resources departments, usually in the name of pay for performance. Some of the earlier ones reflect more of an “angry young man” stage in my career. Today, I’ve chosen to highlight the last of the articles, originally posted on March 14th, 2007. The contemporary commentary on this article had to be modified between printing the galley copies in May and final publication in August and I’ve added an additional post script exclusive to this blog…

Where Comparative Pay Scales Come Unstuck

How do pay scales come about? How do job descriptions get assigned to a pay grade? How do compensation bands get assigned to those pay grades? And how do HR departments decide how much is fair pay to offer a candidate applying for a job? To be mildly unkind, they are thick as thieves with all the other HR folks! They meet usually twice per year to compare pay scales and compensation bands with other companies in the same metropolitan area or industry, and they use salary surveys and other analyst research data to build a map of what compensation levels are appropriate for particular positions. They accumulate mean and median information, spreads of variation, and distribution curves for different jobs. This data allows them to assess upper quartile, median, and lower quartile pay, often accurate down to the percentile.

At a higher level, usually the executive committee of a business decides which percentile or quartile they want to target for their employees. If for example, an executive committee decides that their strategic positioning is as the cost leader in a market, they might decide that as part of that policy they want to pay only lower quartile salaries. Hence, low cost also means cheap or poor quality staff, presumably leading to poor quality service and products—but at a cheap price.

This would imply that an organization that wants to be merely mediocre would instruct its HR department to enforce a policy of, say, median (or fiftieth percentile) pay for its employees. Congruent, is it not?

STOP RIGHT THERE!

When did you ever meet a strategic planning department that would openly state, “Our goal is to be mediocre!” How motivational do you think that would be? Can you imagine the posters around the office—Master Mediocrity—Strive for Median Performance—Competing is Better than Winning!

And you get my point!

Companies that state, “We want to be Number One in the [insert subject here] market,” “We will dominate the market for [insert product] in [insert geographical region],” and so on, are declaring that they want to be the best. So how do you reconcile that with, for example, a recruiting policy of targeting the sixtieth percentile in an industry?

I like to call the proper alignment of goals with recruitment policy the “Kenny Dalglish School of Management.” Dalglish was the most successful football player ever to come out of Scotland.* Arguably he has to cede the position as best-ever manager to Alex Ferguson, but Dalglish’s managerial record is very impressive, having won the English league trophy on several occasions with two different clubs. He took the second team, Blackburn Rovers, from the Second Division to the championship in under five years and thus proved that he hadn’t been lucky the first time around with Liverpool. Dalglish had a simple approach to management. He believed that you had to optimize each part in the system to be the best. So, if you wanted to concede the fewest goals in the league, you needed to have the best goalkeeper. If you wanted to score the most goals, you needed the best striker. And so on. He consistently broke transfer records to sign the best players to his team, thereby denying those players to the competition. His actions were aligned with the goals of his employer. Consider this snippet from his Wikipedia page:

1994–95 saw Dalglish again break the transfer record, paying Norwich City £5 million for Chris Sutton who along with Shearer formed a formidable striking partnership. He had now spent £27¾ million putting together a squad that could make a serious challenge for the ultimate prize, the Premier League Championship. The challenge came and by the last game of the season both Blackburn and Man United were pushing for the title, Blackburn had to go to Dalglish’s former home Anfield with United having to go to East London to face West Ham United at Upton Park. Dalglish smiled as Rovers went 2–1 down to a late Redknapp winner and the news that United had failed to get the result they needed filtered through to him via the radios in the crowd.

At Blackburn Rovers, club owner Jack Walker wanted to win the championship. He hired Dalglish to make it happen. Walker wanted to be number one. Dalglish hired the best by paying the most and delivered the prize.

Now ask yourself this, “Are your employer’s strategic positioning and stated goals aligned with the recruitment and compensation policies?”

Further, consider whether one blanket policy—a one-size-fits-all approach— to define the targeted pay band is appropriate? For example, if your employer has a goal to be number one in service, but a goal of lower costs in widget manufacture because the widget market is coming under price pressure and has been commoditized by competitors, would you have a single policy on recruitment and compensation, or would you tailor those policies according to your strategic plan? Mightn’t it be better to have an upper-quartile policy for people who can deliver on the goal of being “number one in service,” while other areas of the business might rightly have a third quartile policy?

Contemporary Commentary

As this book goes to print, Kenny Dalglish has just been fired from his second stint as manager of Liverpool Football Club in England. He took the position initially on a temporary basis during the 2010–2011 season. In the beginning, he appeared to rely on his stature and reputation to inspire the team to improved performances. In the summer of 2011, he was rewarded with a three-year contract.

Once again Dalglish entered the transfer market and paid high prices for three of England’s top international players. During the 2011–2012 season, his team had mixed results. They performed well in cup competitions, winning the trophy traditionally known as League Cup and reaching the final of the Football Association (F.A.) Cup. Performances in the Premiership league competition were lackluster, resulting in a mid-table finish.

P.S.

This article was written at a time when I suffered the frustration of working with an HR department that had a stated 3rd quartile compensation strategy for all employees across the firm regardless of function or relevance to the company’s ambitions. However, the incoming CEO had wanted to position the future of the firm as a world class innovator and leader in the field of digital intellectual property rights management. To build the kind of IT systems that would meet his expectations and impress the company’s owner was going to require some of the staff to be better than the mediocre level implied by 3rd quartile compensation.

Also put yourself in my position as a middle manager and junior executive being told by the HR associate that the policy is 3rd quartile compensation. The implication is either “that’s right we think you are mediocre too” or “hey, you’re only here because you were cheap.” Are you feeling inspired? I’d like to think it was the latter reason in my personal case

Sunday, August 26, 2012

Develop Change Management Capability

This is the second post in my series related to change management and evolutionary capability, following Change Management vs Process Evolution on Friday.

It seems our world is full of lots of advice on how to do things better, or properly, and suggestions on what we should improve and to what we might change. However, the advice on how to introduce, lead and manage change is to found elsewhere. The Capability Maturity Model Integration (CMMI) - a model for process improvement - does not contain a process area for Change Management. The Project Management Institute (PMI) does not have a Community of Practice (CoP) for Change Management or even Process Improvement. It seems to me these are massive omissions.

I believe that managers need to be pro-active about building a Change Management capability and looking beyond traditional 20th Century managed change, they should be architecting their organizations with an evolutionary change capability - pro-actively developing and nurturing such capability.

CMMI

As regular readers know, I’m very familiar with the Capability Maturity Model Integration (CMMI), both understanding its history and roots in the work of Deming and Crosby, and in my observation that we don’t need an Agile Maturity Model because Agile transitions and organizations maturing while adopting Agile methods, appear, by-and-large to follow the existing CMMI model.

Proponents of CMMI advocate that it is a model for process improvement and many CMMI based change initiatives are based on “filling in the gaps” between what the model suggests and the current appraisal of the organization. In order to “fill in the gaps” a change initiative is planned and managed - perhaps over several years. Strange then that the CMMI omits Change Management as a required capability. It appears that appraising the change management capability of the organization and accurately assessing the organizations ability to successfully implement the changes a CMMI appraisal might suggest, is left as an exercise outwith the scope of the CMMI, or the process improvement initiative.

It seems to me that it is either assumed immature organizations have the capability to manage complex elaborate change programs despite the fact they can’t manage complex and elaborate projects and programs, or, it is assumed that somehow the CMMI Lead Appraiser’s consulting firm will do it for them. This assumes that the client company has a strong capability at vendor management which it almost certainly doesn’t - this would have been revealed in the appraisal one way or the other, but it is generally not a strong capability of most high tech firms and software development organizations.

PMI

Meanwhile, the other strong source of traditional advice and guidance, the PMI, seems to have a narrow and myopic focus on projects and portfolios and is blind to the greater organizational requirements needed to run a successful technology business. Why is there no Community of Practice for process improvement or change management within the PMI? It seems to me that these capabilities must not be valued in the project management tribe. Hence, they have no traction. And yet, if PMI guidance is to be implemented successfully, organizations must manage change. Another one for the consultants perhaps?

Success Lies in Managing Change

From the comments to my first post in this series, it seems the message that change initiatives fail more often than projects, resonates with many. Any yet, senior managers are seduced by big ambitious change initiatives over and over. The utopian nirvana of the promised end-state is like a shiny new object that romances them and they fall blindly in love with its promise. This blindness extends to the failure to recognize that they do not oversee an organization capable of managing such a change nor selecting and managing a vendor capable of assisting them with it.

So what to do?

Like every other required capability, you need to learn and practice change management. Start small. Practice it often. Gain confidence from small successes. Learn from small mistakes. Implement fast feedback loops on small changes to enable learning.

This begins to sound a lot like Kaizen - small changes, implemented often - continuous improvement! Like continuous deployment - you get good at it by deploying and by gradually learning how to do it more often - and you learn that it is more successful when you do it often and in small steps - like automated unit and regression testing - small check-ins often lead to more successful results and develop capability. And so it goes with change management - start small, implement small changes often, learn from the experiences and improve, gradually larger changes will be possible as your capability grows.

As we already know, Kanban is a means to implement a kaizen culture and develop small, continuous improvement capability. Hence, implementing the Kanban Method is a means to develop change management capability.

Conclusions

Change Management is a heavily overlooked and under-rated organizational capability. Change Management is missing from the models, advice, guidance and communities of organizations we’ve traditionally looked to for guidance and authoritative advice on managing technology development businesses. Successful change initiatives require a strong organizational capability in change management. Organizational capability is build by starting small and practicing often. Kaizen is a means to build such capability and Kanban is a means to implement Kaizen. Implementing the Kanban Method in your organization can lead to greater success delivering significant change initiatives.