Tag Archives: agile management

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. Automated software testing tools are 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