Posts about agile management

Magnetic White-Board Kanban Card Options

Just some quick ideas for Kanban whiteboard magnetic card options from a question I answered on Reddit.

Here is the best lean solution: Trying Out My Agile Kanban Board from Jon Miller.

kanban board with magnetic whiteboad  cards

Magnetic kanban board from Jon Miller.

Why, well mainly I am kidding about it being the best, but if you don’t read his Gemba Panta Rei blog you should! Go add it to your RSS feed reader, before you continue with this post.

Ok, welcome back. In addition to thinking his blog is great the solution from his blog is very flexible and easy – though it isn’t quite a packaged solution (as asked for on Reddit). Also that post provides some good insight into the thinking behind the board (as well as how to create your own).

More links with kanban board options: Magnetic whiteboard cards (50-pack)Physical TaskboardsI think just magnetic symbols (not magnetic white board card) but could use magnet with icon to stick paper to the board

Another silly site, that sells some sort of solution, blocked my access because they don’t sell in the country my computer reported being located in. So I didn’t give them a free plug (assuming their product was decent which it might be?). Very dumb design if you ask me; well even though you didn’t ask, I told you anyway.

Localization that impedes users rather than helping them seems far far too common in my experience. Mapping (and related – find closest…) uses are about the only localization stuff I find useful – country based localization I nearly always find annoying or crippling. And showing my location on a map is totally awesome (especially as I travel around as a tourist – or really in whatever capacity). Such bad design and poor usability decisions cost companies money.

Related: Visual Management with Brown M&MsMaking Data VisibleDeming and Software Development

Software Process and Measurement Podcast With John Hunter

In my podcast with Tom Cagley, Software Process and Measurement Cast: John Hunter on Management Matters, as you might expect there was a bit of a focus on software development and agile software development as related to the ideas I expressed in Management Matters: Building Enterprise Capability.

photo of John Hunter at the Borobudur Temple

John Hunter at the Borobudur Buddhist Temple in Indonesia.


Continue reading

Agile Story Point Estimation

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

Related: Assigning Story Points to Bug FixesMistake Proofing the Deployment of Software CodeChecklists in Software Development

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

Continue reading

Pull Consulting: Immediate Management Consulting As You Need It

2013 UpdateNew method for by the minute consulting with John Hunter.

As happens in this fast paced world this service is no longer available. The company has shut down their web site.

I think the potential for consulting as you need it is great. I actually was looking into creating an application to support the ability to provide this service with someone else; but we just had too many other things going on. I have now made myself available for consulting you pull as you need it through MinuteBox. You can get consulting when you need it for as little time as you need.

So if you are trying to apply the ideas I discuss on this blog and run into issues you would like to get some help with connect with me and you can get some immediate coaching on whatever you are struggling with. I am offering a special rate of $1.99 a minute, for now. The graphic on the right of this post (any post on this blog, actually) will show if I am available right now (as does johnhunter.com). If so, you can connect and get started. If not, you can leave a message and we can arrange a time.

I am featured on MinuteBox with this cool graphic, isn’t it nice :-)

home page of MInute Box with John Hunter graphic

John Hunter feature on Minute Box homepage

One advantage of this model is that those of you following this blog have a good idea of what topics you would like to delve into more deeply with me. If you have any questions on a particular topic you would like answered today or arranging coaching on specific topics over a period of time or help planning a project or someone to bounce your ideas off give this consulting as you need it model a try.

For those of you management consultants reading this blog (I know there are many) you can create your own Minute Box account easily and provide this service also. And even if you are not a consultant if you have advice worth sharing (and I know there are many of you also) you can also set up an account.

Related: John Hunter’s professional life timelineJohn Hunter onlineJohn Hunter LinkedIn profileTop Leadership blogsTop Management and Leadership blogs

Management Improvement Blog Carnival #156

The Curious Cat Management blog carnival highlights recent management blog posts 3 times each month. The posts generally focus on the areas I have focused on in the Curious Cat Management Guide since 1996 (Deming, evidence based management, lean manufacturing, agile software development, systems thinking…)

  • The Key Questions for a Minimum Viable Product Project by Anthony Panozzo – “What are you trying to learn with this particular MVP?
    What data are you collecting about your experiment?
    What determines the success or failure of the experiment?” [bold added - John]
  • Less Process, More Discipline by Charlie Martin – “Without it, you lose everything agile methods promise. The key to agile methods is this: You may have less process, but you must have more discipline.”
  • Sunset over Andaman, Khao Lak, Thailand

    Sunset over Andaman, Khao Lak, Thailand. By John Hunter

  • Evaluating Executive Performance by Art Smalley – “One interesting thing that I will note that was considered in Toyota in Japan by the HR department when evaluating executives was how their previous departments fared after they had left. If the department continued to improve then this was generally a good sign.”
  • The evolution of design to amplify flow by John Hagel – “If we want to remain successful and reap the enormous rewards that can be generated from flows, we must continually seek to refine the designs of the systems that we spend time in to ensure that they are ever more effective in sustaining and amplifying flows.”
  • Continue reading

Avoiding Tragedy of the Commons for Software Development

Kanban and Tragedy of the Commons

The “Tragedy of the Commons” archetype often manifests itself through “Shared Services”, when a small number of people with specific skills, work across different teams. Each team in isolation gets benefit from the Shared Service, but when demand for the service exceeds its capacity, then nobody benefits. At a smaller scale, a team with a low “bus factor”, or a hero, can also suffer from a tragedy of the commons, when too much work is dependent on a single person.

One of the comments on this post suggested that the tragedy of the commons wasn’t an accurate description. My comment:

I think the “tragedy of the commons” analogy works. As long as the users don’t have pay for use (or decide to prioritize) the danger exists for the abuse. So if you have a developer team and everyone just gets to dump tickets on to them and then whine if they don’t get what they want, when they want, I see the analogy as accurate. If people can just treat a resource as though it was suppose to just serve them and the resource is overwhelmed I see that as tragedy of the commons.

There are many ways to manage that problem (some manager deciding the priority for example). Then you may have other problems, but may avoid the tragedy of the commons scenario (in reality this setup is often done, but most don’t accept the prioritizations and just expect the development team to get everything done – which means you don’t avoid the tragedy of the commons problem).
Continue reading

Management Improvement Carnival #125

photo of cypress trees in swamp in South Carolina

Photo of Cypress Trees by John Hunter

The Curious Cat Management Blog Carnival selects recent management blog posts 3 times each month. You may submit a link to the management Reddit to have it considered for inclusion in our carnival. More photos from Cypress Gardens, South Carolina.

  • What Next? by David Ing – “The underlying problem is that it seems to come down to having to completely change the culture of an existing business. This can be done internally, and often is done by heroic souls today, but like the advice of how to eat an elephant (‘one bite at a time’) after a while anyone’s going to get pretty sick of tasting just bad elephant every day.”
  • Systems in Place to Prevent These Medication Errors? Seems Not… by Mark Graban – “We’re taught in the Lean methodology that ‘standardized work’ is not just a matter of writing procedures. We need a culture and an environment where standardized work is actively managed.”
  • Driving Out Fear and Other Similarities Between Drucker and Deming by Kelly Allan – “[Drucker] Inherent in the managerial task is entrepreneurship: making the business of tomorrow. Inherent in the task is innovation. Innovation is above all, top-management attitude and practices. [Deming] The moral is that it is necessary to innovate, to predict the needs of the customer.” (Deming on Innovation – John Hunter)
  • The second death of agile by Niklas Bjørnerstedt – “Agile should evolve, but I think it should not loose its focus on software. If you are interested in “agile” outside of software you should study systems thinking. Why reinvent the wheel? The combination of systems thinking and agile is much more potent that some new bloated variant of agile.”
  • Lean’s Fork In The Road by Bill Waddell – “They are driven by the idea that the future is unknown, but if you continually improve the processes for getting work done you will be in good shape, no matter what the future holds. Do the work well in terms of minimal waste, excellent quality, driving yourself to take the best care of customers, and things will turn out all right. Better than all right, in fact…”
  • Continue reading

Assigning Story Points to Bug Fixes

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

Related: Future Directions for Agile ManagementMistake Proofing Deployment of Software ApplicationsChecklists in Software Development

Annual Management Blog Review: Software, Manufacturing and Leadership

In my contribution to the 3rd annual management blog roundup I will take a look at 3 blogs: Dennis Stevens, How to implement “Lean Thinking” in a Business and the Three Star Leadership Blog. This year 14 management bloggers contributed to highlight over 40 blogs, be sure to check out all the posts.

photo of Dennis Stevens

Dennis Stevens


Dennis Stevens writes a blog of the same name focused on agile software development principles with a strong focus on Dr. Deming’s ideas and lean thinking.

  • What’s Deming got to do with Agile – “Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work… In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities.”
  • Kanban Mental Models and Double Loop Learning – “the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.”
  • We are Doing QQ All Wrong- “Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests… Test driven development or test just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation.”
  • Shorten and Reduce Variability in Lead Times Using Kanban – ” identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.”
photo of Tracey Richardson

Tracey Richardson

Tracey Richardson writes the How to implement “Lean Thinking” in a Business blog focused on the lean manufacturing and the Toyota Production System.

  • Common Mistakes when we are Problem Solving – “Not utilizing the ‘Power of the gemba’,–or often referred to as “Go see the work/process“.!! I often see teams working together in a room trying to solve the problem by using their experiences, hypothetical guesses, and what their opinion is. I quickly disperse the huddle to “go-see” with their own eyes the current situation.”
  • How many different types of A3’s are there? – “I will briefly describe the 4 different types of A3’s and when to use them based on my experience: Problem Solving A3, Proposal A3, Status Report A3, Strategic Planning A3. All A3’s should follow the PDCA thinking regardless of which type you are working on.”
  • Why is asking “Why” so important? – “It is important to ask why repeatedly when visiting the gemba to determine what is current happening versus what should be happening. In many cases we stop at a symptom to the problem because we are often pressured for results and quickly solving the problem without going past the symptom seems to be the best answer.” [this one is actually from 2009 but I included it anyway - John]

The Achilles’ Heel of Agile

Guest post by Jurgen Appelo

When I wrote this, I was working in a big open office space in the Van Nelle Factory in Rotterdam (see photo). About 100 people work in an office that was the first of its kind in Europe, when it was built in 1929. And more than 80 years later, architecture lovers from all over the world still come to admire it, take pictures, and make drawings. I sometimes waved at them.

photo of open office style at Van Nelle Office
Van Nelle office, reprinted by permission of Stephan Meijer

A big open office space has advantages and disadvantages. Advantages are flexibility and easy communication. The main disadvantage is that it is a shared resource for all who work there. Climate, sound, and light are hard to manage in a space like that, and the optimal configuration for the whole is never optimal for all. But our office manager did the best she could in trying to maximize pleasant working conditions, while maintaining tight rules to keep things under control. A shared open office is not the ideal environment to give people full responsibility over their own working space.

Self-organization is usually promoted in agile software development. But when shared resources are not managed by a central authority, self-organization often results in the Tragedy of the Commons. The name refers to a situation in which multiple self-organizing systems, all acting in their own self-interest, overexploit a shared limited resource, even when they all know it is not in anyone’s interest for this to happen. The impact that humanity has on CO2 levels in the air, trees in the forests, and fish in the sea, is right now the most debated and intensively researched case of the Tragedy of the Commons. Organizations also have shared resources, like budgets, office space, and system administrators. We could see them as the business-equivalent of the air we breathe, the landscape we change, and the fish we eat.

Research indicates that four ingredients (called the four I’s) are needed for sustainability of shared resources [Van Vugt 2009:42]:

  • Institutions [managers] who work on building trusting relationships between competing systems [teams] in order to increase acceptance of common rules;
  • Information that increases understanding of the physical and social environment, in order to reduce uncertainty (because uncertainty results in bias towards self-interest);
  • Identity, or a need for a social “belonging” that encompasses all participants, to improve and broaden one’s sense of community and reduce competition between teams;
  • Incentives that address the need to improve oneself, while punishing overuse and rewarding responsible use.

Research shows that it is imperative that there is some form of management (or governance) to protect these shared resources by working on these four I’s. (I realize that most modern day governments are not setting a good example of how to do that.) In the case of shared resources, whether it concerns money, space, or system administrators, someone outside of the development teams must keep an eye on long-term sustainability instead of short-term gains by individual teams.

The Tragedy of the Commons is the Achilles’ heel of Agile. It takes management to protect that heel, in order to prevent teams from depleting resources, and crippling the organization.

This article is an adaptation from Management 3.0: Leading Agile Developers, Developing Agile Leaders, by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series.

Related: Embrace Diversity, Erase Uniformitymanagement 3.0agile software development booksVW Phaeton assembly plant

No True Lean Thinking or Agile Software Development

“There is no true value of any characteristic, state, or condition that is defined in terms of measurement or observation.” – Dr. W. Edwards Deming.

The value depends on your operational definition.

Once you operationalize management ideas in a real organization it necessarily should have differences from how it is operationalized elsewhere. As Deming said there are no effective simple recipes for management. It is one of the frustrations people have with Dr. Deming: that there is no cookbook telling you what you should go do as a manager. You need to understand things like: interactions, variation, psychology, systems thinking, how we know what we know (and what we “know” that isn’t so). And then you need to make decisions about how to apply these concepts in your organization.

There is value in being able to think and discuss ideas in a broader context than your organization. You lose a great deal of learning opportunities if you can’t. And having common idea about what common principles a lean thinking organization or agile software organization should have is helpful I believe. That is aided by abstract ideals of these management practices.

Dilbert comic on the futility of process and arbitrary deadlines

One of agile’s guiding principles is individuals and interactions over processes and tools. I am a Deming follower and that emphasizes the importance of process and system. The words in agile are anti-process. But in my experience it is really a specific type of process – and that is basically idiotic adherence to process that the software developers are sick of. This attitude is best summed up in Dilbert. There are plenty of what I would call process in the practice of agile – sprints, kanban, work in process limits, define what done means, using user stories, retrospectives, build in quality… Basically I think it is important to understand what the principles mean, but don’t get locked into dogmatic ideas.

There are principles that seem to me necessary to, for example, consider an effort as lean management. There must be respect for people in lean management. If it isn’t there, then I don’t think it is lean. It might be management using some ideas and tools from lean, but it isn’t lean management. Exactly how respect for people is manifest is up to the organization. The same thing holds for other principles.

Thoughts on No True Agile, No True Lean, No True Latte

Related: Dr. Deming: There is No True ValueHow to Manage What You Can’t MeasureInvolve IT Staff in Business Process ImprovementThe Illusion of Knowledge

Continue reading

Involve IT Staff in Business Process Improvement

I started out basically working on management improvement from the start of my career. My makeup (I am never satisfied and figure things should always be better) along with a few traits, experiences and probably even genes made this a natural fit for me. I tend to take the long view and find fire fighting a waste of time. Why fix some symptom, I want to fix the system so that problem doesn’t happen again. My father worked in statistics, engineering and business improvement and as I was growing up I had plenty of experience with process improvement, understanding variation, experimenting, measuring results

I came into the IT world as I had needs and found the best solution was to write some software to help me accomplish what I wanted to. One thing that better software tools allowed is this type of thing when organizations failed to use technology well, individuals could just do so themselves. Without these tools people had to rely on the organization, but today atrophied IT organizations can often be circumvented. Though the IT organizations often try to avoid this largely by bans (instead of by providing the tools people need), which is not a good sign, in my opinion.

I then spent more and more of my time working with technology but I always retained my focus on improving the management of the organization, with technology playing a supporting role in that effort. That is true even as where I sat changed. And I have become more convinced organizations would be served well by using the information technology staff as business process experts.

At one point I sat in the Office of Secretary of Defense, Quality Management Office where I was able to focus on management improvement and using technology to aid that effort. Then I went to the White House Military Office, Customer Support and Organizational Development office and focused largely on how to using technology to meet the mission. Then I was moved into the White House Military Office, Office of Information Technology Management.

And now I work for the American Society for Engineering Education in the Information Technology department. My role started as partially program management and partially software development and as we have grown and hired more software developers I am now nearly completely a program manager.

I believe technology is a central component of understanding business processes today. But the truth is, many business people don’t have as complete an understanding as I feel they should. Now I believe, most anyone interested in planning their management career needs to develop a facility with technology and specifically how to use software applications to improve performance. You don’t need to be an expert programmer but you need to understand the strengths, weakness, limits of technical solutions. You need to understand how technology can be used (and the risks of options).

At the same time I just don’t think it is likely management everywhere will get a decent understanding of application software development. I also believe that in many cases organizations should do software development in house. This is a issue that certainly can be argued (but I won’t do it here). Basically I don’t think organizations should cram their processes into designs required by off the shelf software. Instead I believe they should design processes optimal for their organization and using off the shelf software often does the opposite (forces the process decisions around what software someone decided to buy). There is plenty of use for off the shelf software that doesn’t force you to make your processes fit into them (and sometimes even if it does that is the business decision that has to be made – I just think far too often organizations look at short term costs and not the overall best solutions for the system).
Continue reading

Toyota’s Journey to Lean Software Development

Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.

Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?

via: Justin Hunter

Related: Toyota IT OverviewToyota Canada CIO on Genchi Genbutsu and KaizenLean Software DevelopmentMy First Trip to Japan by Peter ScholtesToyota IT for Kaizen

Improving Software Development with Automated Tests

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. But it is a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Related: Combinatorial Testing for SoftwareMetrics and Software DevelopmentChecklists in Software DevelopmentGoogle testing blogHexawise software testing blog

Baking in Quality to Software Development

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.

Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.

Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.

The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.

An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentSoftware Supporting Processes Not the Other Way AroundSoftware Development and Business Process SupportTop Blogs for Software DevelopmentHexawise: more coverage, fewer tests (my brother’s company)

The Importance of Making Problems Visible

Great, short, presentation webcast by Jason Yip showing the importance of making problems visible. Anyone interested in software development should watch this, and it is valuable for everyone else, also. Great visuals.

Related: Future Directions for Agile ManagementAgile Software Development SlideshowLeading Lean: Missed OpportunityInformation Technology and ManagementCurious Cat Micro-financiersposts on project managementToyota Institute for Managers

CMMI and Agile Development

CMMI or Agile: Why Not Embrace Both! is a new report that is worth reading.

All too often, CMMI has been applied rather than implemented. The standards-centric application of CMMI has contributed to some spectacular failures and losses of time and money. The key difference between applying and implementing CMMI is that applying usually appears as a superimposition (or overlay) of model practices onto existing activities with an expectation of producing the example work products found in the model, rather than seeking the natural products of the organization’s processes. This misplaced focus is often the by-product of an overly strong focus
on achieving a particular appraisal rating.

In contrast, implementing CMMI is using the model in the same way that engineers and architects use models: as a learning tool, a communication tool, and a means of organizing thoughts. The more implementation-oriented an organization is, the more improvement-centric it is; thus, the focus is on maturing and growing process capabilities rather than ratings.

CMMI and Agile can complement each other by creating synergies that benefit the organization using them. Agile methods provide software development how-to’s that are missing from CMMI best practices that work well—especially with small, co-located project teams. CMMI provides the systems engineering practices that help enable an Agile approach on large projects. CMMI also provides the process management and support practices that help deploy, sustain, and continuously improve the deployment of an Agile approach in any organization.

Related: Stretching Agile to fit CMMI Level 3Microsoft CMMIAgile Management

Management Improvement Carnival #47

Read the previous management carnivals. Also see the management Reddit for popular new blog posts to include in future carnivals.

  • The Decline and Fall of Agile by James Shore – “Without XP’s agile engineering practices, code quality and productivity asymptotically decreases over time. With them, productivity starts lower, but then it asymptotically increases.”
  • How Do You Measure Success? by Ron Pereira – “First of all, I believe many companies get caught measuring the wrong things… my favorite productivity metric is sales per employee. Of course some will think I’m advocating cutting heads in order to drive this metric up. I’m not.”
  • No Excuses by John Shook – “A culture of management seeking where to place the blame — the five whos — will absolutely prevent the flourishing of a culture that fosters ubiquitous use of the five whys”
  • Resource Planning by Jurgen Appelo – “Considering that task-switching is bad, the resource planner must seek to minimize the number of different activities per week, per person… Software developers themselves are allowed to reserve a number of academy days. These are days for self-development and training.”
  • The Deming Chain Reaction by John Dowd – “According to Deming, quality is not a state to be achieved in manufacturing, but is, rather, an ongoing company-wide effort at continual improvement.”
  • Continue reading

Agile PDSA

Dr. Deming encouraged the use of the Plan-Do-Study-Act cycle to improve. Agile Management encourages a similar mindset – to test out ideas in practice and adapt quickly. A key to both strategies is to quickly iterate over possible solutions. Tesco provides an example of this strategy:

This was our first opening since we took our 12 week pause, after we had opened 61 stores at breakneck speed. We used that time to reflect on what customers had told us they liked, and what they’d like to see improved – and then to improve the shopping trip for them.

For example, customers told us that they really liked our prepared meals, made fresh daily in our purpose-built kitchen, but they wanted a wider selection to choose from. So we’ve developed and introduced a number of new products for them.

Of course, you could argue that this is all a sign of weakness, that we had got things wrong. But that would be to misunderstand the way we do business.

Listening, and then acting on it, is in our view the way to build long-term relationships with customers. It means our shopping trip is always improving, and staying in tune with changing needs. It’s a simple win-win. Customers get a better and better shopping trip, and we become more successful.

At the time Tesco paused the expansion I mentioned it seemed to me they should have allowed more time for PDSA.

To me, it is enormously important to design management systems that support and encourage continual improvement. That is much more important than superior results today. Results today are also, important, but a choice between an inflexible system that produce good results today and a flexible system with results not quite as good is not a close choice. Good management improvement requires continual improvement and therefore systems must be designed to support and encourage continual improvement.

Related: Experiment Quickly and OftenI own Tesco stockmanagement improvement tipsTesco: Lean Provision

Future Directions for Agile Management

Agile management (agile software development specifically) is something that makes a big difference in my work life. David Anderson consistently provides great ideas on agile management and he does so again in this 90 minute presentation on the future directions for agile. As I learned about agile software development, what I saw was a great implementation of management improvement practices focused on software development that was very compatible with Deming’s management philosophy and lean thinking practices. The Agile manifesto:

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

The first line can seem to be at odds, but I think in practice it is not – though I admit it may seem that way based on the importance placed on process by Deming (I think you have to read on agile to understand why this is the case). For my use of agile software develop, a highlight of the most important ideas is:

  • Deliver working systems quickly (with limited features, add features based on user needs) – [management improvement practice: PDSA, pilot ideas on a small scale, go to the gemba (don't sit in conference rooms talking about what might be an issue for the computer application you want to see in 6 months, create working systems and then continually improve it)]
  • Build systems that cope well with uncertainty and allow for constant continuous improvement of processes (with IT systems that can adjust as needed to changing business conditions and desires) – [continual improvement - what is good enough today is not good enough next year]

Important concepts addressed by agile management: highly collaborative, risk tolerance, systems thinking, customer interaction, craftsmanship ethic [joy in work], eliminate waste. Great quote from the webcast:

What we know about knowledge work, and software engineering, is that coordination cost grow non-linearly with batch size. We’ve known this since Greg Brooks published the Mythical Man Month, probably longer than that. So that is a key difference with manufacturing, coordination costs do not grow with batch size in manufacturing.

Related: Kanban In Software EngineeringManagement Science for Software EngineeringImproving Communicationwebcast of David Anderson talking about applying Agile and Deming’s ideas at MicrosoftWhat is Agile Software Development?

  • Recent Trackbacks

  • Comments