Leaders who publicly demonstrate agile methodologies and promote them top-down drive their organizations to sustain agile practices and succeed. But bottom-up agile transformations lack resiliency and generate cultural strife.
Taiichi Ohno, agile coach for Toyota and its executives
Agile methodologies are now widely recommended for managing software development, but most large companies require transformation from entrenched “waterfall development,” an intuitively appealing strategy that has created massive project disasters (see Why Software Fails). Traditionally, most large agile transformations have been pursued bottom-up. One approach starts with a single team, proves agile works, and then expands further and higher in the organization. Hopefully that agile team’s success inspires others to become agile. Another approach religiously converts all engineering teams to adopt a specific agile methodology, but leaves management teams and hierarchies, dependencies, promotion policies, job titles, roles, recruiting and budgeting in their previous form. The developers adopt agile, but the managers don’t. Continue reading
Using an agile methodology for project management can help CEOs, organizations, managers, teams and individuals rapidly adapt to change, beat slower competitors and win profitable markets. Agile methodologies were created to prevent the frequent and expensive manufacturing and development failures that arose in “waterfall” or “ad hoc” projects.
Waterfall vs Agile Methodology
Most people tackle large projects using an intuitively obvious approach called “the waterfall method”: plan a sequence of activities upfront (for example: design, prototype, build, test, deploy), then focus on one type of activity after another until they have completed the whole thing. Only in the end do they have something of value. From software development to car manufacturing, the modular sequencing in waterfall has proven extremely risky, resulting in multi-million dollar project cancellations and corporate bankruptcies. The problem arises from the enormous costs that precede real-world testing. There’s a lot of risk riding on the final stage. Continue reading
Agile Leadership Patterns
Dan Greening and Jeff Sutherland will discuss Agile Leadership Patterns: The Agile Way of Doing at the Agile 2015 Conference, August 3–6, 2015. Join us and learn to answer the questions, “Am I agile?”, “Is my organization agile?” and “Are my leaders agile?” You only need to know five patterns.
Are you exploring agile/lean management practices? Submit an agile/lean research paper or experience report to the Agile/Lean mini-track at the Hawaii International Conference on System Sciences (HICSS). The Agile/Lean mini-track at HICSS has been operating continuously since 2007. Influential papers on Scrum patterns, agile metrics, lean forecasting, qualitative grounded inquiry, distributed development and large-company experience reports have appeared in past years.
The HICSS conference, sponsored by IEEE, brings together a broad cross-section of researchers in system sciences—including software development, social media, energy transmission, marketing systems, knowledge management and information systems. Agile and lean management practices apply to all of these fields. HICSS 49 will be held January 5-9, 2016 in Kauai, Hawaii.
If you are researching or innovating in applying agile and lean principles, we welcome your submission. The full call for papers is here: Agile/Lean HICSS-49 Call for Papers.
Help us extend the agile and lean frontier, by presenting your work at HICSS.
If you want to get an awesome job with the least effort, jazz up your job search with agile self-management (Tweet). Agile methods will help you rapidly discover which of your skills match employer’s true needs, market yourself for better results, target “channels” that have the best opportunities, hone in how much to ask for, and land a great job.
Agile job seekers rely on six fundamental agile patterns to fuel a successful search. In this installment, we’ll focus on the Responsibility pattern. To “accepting responsibility,” in this case, means taking the attitude that everything that happens in your job search, good and bad, is something you caused—you own it. Continue reading
Agile posits this trade off: that creative projects, such as software development, have such huge market, technical and budget uncertainty, that we should pay the high expense of repeated regression testing, packaging, deployment, and rework, to enable us to test our market and technical theories early and often, adapting our approach as we learn more.
Here is my elevator description of Scrum: it is rhythmic experimentation to improve production.
You don’t need agile/Scrum methods if you are certain of market, process and technical perfection or near-perfection. We have nothing to learn with such certainty, so experimentation is useless.
However, the billions of dollars wasted in failed software projects (see IEEE Spectrum 2005, “Why Software Projects Fail”) at abject failure rates exceeding 50% indicate that confident waterfall engineers are dangerously arrogant. We have much to learn about making more successful software projects. It is true that there are charlatans and religious zealots in the agile crowd, and I apologize for them, but there is growing evidence that agile practices are highly correlated with successful, low-cost projects, and enormously successful startups.
You may be interested in what Senex Rex does. Our mission is to help clients become highly profitable long term. When our clients make more money, they have greater freedom to innovate and their employees and shareholders have more freedom to enjoy life. We happen to think agility helps in many cases, so we often teach and coach agile theory and practice. Few contractors teach clients how to sustainably retain and improve agility; we specialize in that. We have many other tools in our tool box. Here’s a snapshot of the work Senex Rex did in February 2014. Continue reading
Join us at the Lean Kanban North America 2014 conference. I will be speaking on the Managing Risk Track, May 7, 2014 from 2:20pm to 3:45pm.
Agile and lean processes make it easier for organizations to measure company and team performance, assess risk and opportunity, and adapt. My colleagues and I have used delivery rate, concept-to-cash lead-time, architectural foresight, specialist dependency, forecast horizon and experiment invalidation rate to identify risk, and focus risk-reduction and learning efforts. With greater knowledge, we can eliminate low-opportunity options early and more deeply explore higher-opportunity options to maximize value. We have used these metrics to diagnose agility problems in teams and organizations, to motivate groups to improve, to assess coaching contributions, and to decide where to spend coaching resources. We face many problems in using measurement and feedback to drive change. Manager misuse or misunderstanding of metrics can lead organizations to get worse. Teams or people that mistrust or misunderstand managers often game metrics. And yet, what we can’t measure, we can’t manage. So part of a successful metrics program must involve creating and sustaining a collaborative, trusting and trustworthy culture.
We feel a little embarrassed that we didn’t announce Troy Magennis was one of two Brickell Key award winners, when it happened in 2013. This award is granted to people who have shown outstanding achievement, leadership and contribution to the Kanban Community. Continue reading