Showing posts with label lean. Show all posts
Showing posts with label lean. Show all posts

February 19, 2023

The Other Reason I Stopped Blogging

I blogged a fair amount (for me, and relative to many colleagues) before I went into consulting and continuing on into my time at Leading Agile -- right up until it became mandatory. The company had a desire to have more people write more content more often so it became expected that everyone be involved. The implementation was a well intentioned across the board writing calendar; a rotation for every consultant to write a blog post when his or her week came up.

That killed my writing motivation. 

I stopped writing. Corporate writing scheduler: "Write something!" Me: "Uh, well, no, and why don't you go pound sand." That's the lack-of-autonomy and lack-of-purpose (ref Pink's Drive) triggers for me. That was part of my writer's block.

Then I got over that (not wanting to comply) and began to think that I just couldn't write on schedule. I could write only when the inspiration hit me. Creativity can't be scheduled. There is some truth to that for me. Much of my writing was in response to either (a) a question someone asked me or (b) an answer someone gave me in response to a question I had. Even in the 1st case, the writing was a thinking tool. It helped me think though how to articulate a point or express a concept for the benefit of others.

It just now hit me that my writing also scratched the itch that Pink in Drive called mastery. As long as I was learning, I was writing. As long as I was learning how to better help others learn, I was writing. 

There came a time when my learning in some old areas slowed, and writing declined. And my learning shifted to a couple new spaces and before I figured out how to write about those things, I changed employers. 

I just discovered an important point about why I didn't start writing again in that new role. I discovered this while reading John Cutler's "TBM 9/52: Writing Culture Challenges". John wrote "A writing culture is a reading culture and a feedback-giving culture. A write-and-reading-and-feedback-giving culture requires time to think, process, and respond. Writing isn't the end goal: thinking and improving is the goal."

That's what happened when a writing schedule was put in place at Leading Agile -- writing was the goal; marketing was the goal. Well, the company's leadership might have known that writing was to develop thinking, but that's not how the expectation was expressed.

Then in the new role, the work-load set it. John says that you don't get a writing culture in "Conditions of high reactivity, cognitive load, and passivity. No one has time or energy to think, ask questions, and process. Too much energy goes into doing and reacting."

John goes on: "…you can't just 'switch' to writing culture. It has very little to do with the writing and everything to do with the preoccupation with busyness, optics, power, control, and tempo. ... Work-in-progess [sic], change-in-progress, and planning-in-progress is just too high to think." Yikes!

John gives some good suggestions, techniques in his article. Worth reading. But he doesn't tell you what to do with the high WIP, high change-in-progress problems in that article. I expect he has in some of his other articles that I haven't read. It's worth subscribing to his articles. 

February 7, 2023

"Value Stream Management is Human" Patterns

In spite of how others are redefining it to be something different, Tapping, Luyster and Shuker defined value stream management in 2002 as an 8-step lean process “for planning and linking lean initiatives though systematic data capture and analysis.” Basically, commit to lean, choose a value stream, map it, pick a future state, and create and implement kaizen plans. It’s improvement. And it’s a human endeavor. Too many people think VSM is about managing-the-work-in-the-system instead of improving-the-system.

Over my career I’ve noticed several approaches to value stream management:

“Unintentional” – Not done on purpose. In this pattern, no one is intentionally improving the value stream. Every org has a value stream whether they realize it or not, whether they think about it or not. This doesn’t mean that the organization is bad or that their value stream isn’t effective, efficient or optimized. Very talented managers could manage a value stream to great effect by pure skill and experience, not conscious of any improvement efforts. They don’t think about it. Others, however, don’t think about it and get “Value Stream Mismanagement”.

“Casual, ad hoc, decentralized and distributed” – This pattern is typified by teams doing their own retrospectives. There is little sharing of lessons learned across teams even though there may be attempts to catalog or share these. No one is driving improvement across the org.

“Intentional and distributed” – In this pattern, there is someone high up, often a CIO or VP, very much interested in process and improvement. This works well, particularly through lean, kaizen, the Toyota Kata, and the Coaching Kata. Multiple techniques/tools are often used such as A3 Problem Solving, systems thinking, and the theory of constraints. There are often measures and metrics, typically lean (flow) metrics. Kaizen moments and retrospectives are encouraged and expected throughout the organization.

“Agile Transformation / Agile Coach / Centralized” – In this pattern, there is an agile transformation initiative driving process improvement efforts. Such efforts are often time-bound, tied to the duration of the transformation initiative. Attention and efforts wane after a time.

“Biz Process Reengineering / Centralized” – This is another form of the “agile transformation” pattern but is more explicit around improving the value stream, and it’s likely much broader than just IT or software development in that it likely includes business operations as well. This might be led by a process reengineering group, expert or consultant and should involve business architects.

“Control” – I insist that value stream management absolutely, chiefly, and primarily includes the concept of improvement. However, some organizations are more concerned with control and reporting of work progress, percent completion, and due dates than with improvement. Not much improvement happens with this pattern. (I first labeled this pattern “PMO”, but decided that wasn’t fair. PMOs didn’t have the best reputation in the heyday of the agile movement. Perhaps that’s changed now, and I’ve seen many PMOs adopt agile and even drive agile transformations with some success.)

The best approach to take is “Intentional and Distributed”.

My purpose for writing this was twofold:

  • I want everyone to understand the true point of value stream management, which is continuous improvement. So many people (platform vendors especially) are making it out to be something else entirely.
  • I hope more people will be intentional about improvement efforts. Perhaps they’ll recognize their pattern and consider other alternatives.

April 8, 2014

My Recent Posts on LeadingAgile

I started working with LeadingAgile in 11/2012 on some complex enterprise agile transformations and other lean management consulting. Related to that, I've done most of my recent blogging over there on LeadingAgile's blog. Here are some of those posts:

I Don’t Estimate Software Defects, but it's not as simple as just that. If you follow my advice, you'll also have a zero-defect mentality and you'll fix defects as soon as you find them. In general, I want a conservative measure of velocity, so I don't record in my velocity anything that was unplanned. Therefore, I likewise Don't Estimate Spikes.

I'm fond of The Theory of Constraints and Brooks’ Law. In that post I evaluated Brooks' Law in light of the Theory of Constraints in a way that I hope helps the reader understand both concepts.

Lack of Predictability is Your Biggest Problem. The senior leadership in most organizations I work with seem to agree. They aren't very interested in agile's agility. They want their design-build-test teams and their program teams to be able to make and meet commitments so they can make appropriate capacity constrained commitments across the portfolio and to external stakeholders.

Agile Health Metrics for Predictability was perhaps my most popular post on LeadingAgile's blog.

In Bottom-Up Implementation & Top-Down Intent, I discuss my recommended approach to agile transformations.

Related to that, I wrote a post arguing that you should fix your Structure 1st: Why You Should Not Start With Practices

Part of your structure involves your design-build-test teams, also known as your Scrum teams. In Use Feature Teams. Yes, Use Component Teams I explaining these approaches and why I recommend using both.

What do Scrum teams do during the Release Sprint? Good question. This post has the answer. In short, many things, but not developing code that can't be tested immediately.

Oh, I also published an article in Agile Journal entitled Identifying and Improving Bad User Stories along with my friend and co-author Chuck Suscheck. We put another article up on sticky-minds: The Problems with Overachievers on Agile Teams.

November 15, 2012

Sketchnotes of Agile Immersion

Here are the sketchnotes from my November Agile Immersion workshop.

These sketchnotes were done by a business partner of mine, Jenny Trautman of evenview. Sketchnotes aren't the main thing evenview does -- sketchnotes are an artifact. What evenview does is help people bring innovative strategies into focus. They lead fun, high-energy meetings using interactive visuals that draw a team together. With their support, groups collaborate to develop a shared vision, create a plan for action, and implement their ideas. Use them for your next strategy meeting or kickoff.

By the way, this workshop is designed for everyone. No agile experience or programming skills required. All types of roles have found it benefical: product managers, marketers, managers, office managers, business development executives, developers, testers, CFOs, and etc. Check out this interesting blog post from a recent non-developer attendee.

December 12, 2011

Yet Another Agile Reading List

(Updated October 2018)

I'm often asked for an agile reading list and each time I wish that I had already blogged it. What's kept me from doing it so far is that I tend to write a somewhat new list each time depending on the requester's level of experience, unique situation, and context. Such a list is also likely to change over time, but that shouldn't stop me from posting it -- this post is my thoughts at this point in time. My thoughts are likely to change.

That said, and without further ado or proof reading, here is an agile reading list.

Getting Started
Just go read the Scrum Guide. If you've never read it, you really should. It's short. But you might need something beyond that to gain a better understanding of how and why agile works, so don't stop there...

I could make this easy for me and just say read Cohn's signature series plus the Beck signature series. That'd keep you busy for a while and cover the topic pretty well.

But I can put a little more effort into this. Don't let this long list scare you. Start with this 1st block, then supplement with some of the others. I'm writing this from the point of view of helping a total agile novice get started.

Most importantly, you need to understand the agile values: http://agilemanifesto.org/ and http://pmdoi.org/ and either http://www.extremeprogramming.org/values.html or http://www.softwarereality.com/lifecycle/xp/four_values.jsp or http://xp123.com/xplor/xp0209b/index.shtml.

Here are some links about agile in general and two specific agile processes, XP and Scrum, and one lean/agile approach called Kanban. Just read as little or as much of these as you desire to get the gist of what it's all about:
http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Extreme_Programming
http://en.wikipedia.org/wiki/Scrum_%28development%29
http://en.wikipedia.org/wiki/Kanban_%28development%29

You need a good understanding of the Scrum process since it's the market share leader right now. I really really like Kenny Rubin's way with words and his Essential Scrum book is excellent. This is good: Succeeding with Agile: Software Development Using Scrum by Mike Cohn. Subscribe to Mike's blog.

Here's a good short, quick, easy to read intro to Scrum: "The Elements of Scrum" by Sims and Johnson. It includes some extra stuff that you really should do if you are using Scrum. I liked that. Well written.

I think I'll throw in http://scrumpocketguide.com/# from my friend Peter Saddington. I haven't read it, but it sounds short. :-)

Alternatives or Slightly More Advanced Items
Subscribe to my blog and LeadingAgile's blog :-).

These next few are a bit old, but you need to have read something by "Uncle Bob" and Alistair. You could substitute some other book by them if you wish:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.
Agile Software Development by Alistair Cockburn.

These eXtreme Programming books are great and short and solidly apply to Scrum:
Planning XP by Beck.
XP Installed by Jeffries.
XP Explored by Wake.
Don't get the original white XP Explained book by Beck. It's talks about Load Factors and Ideal Engineering Days which I don't recommend.

If you want to broaden beyond Scrum and XP, read about Crystal Clear and the other Crystal methods by Alistair Cockburn.

Product Owner
Now we move beyond the basics into some specifics. First, let's take a look at the Product Owner related literature:

http://www.agilemodeling.com/artifacts/userStory.htm

Agile Estimating and Planning by Mike Cohn.

User Stories Applied: For Agile Software Development by Mike Cohn.

Here are some great posts from my colleague on The Product Owner:
http://www.leadingagile.com/2011/03/why-a-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-who-needs-to-play/
http://www.leadingagile.com/2011/03/one-real-life-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-design-considerations/

Scrum Product Ownership by Robert Galen. It's not an intro to agile. It's a good, thorough book on product ownership. It's full of good advice and tips and warnings against certain dysfunctional behaviors. The book contains some typos and passive voice that will annoy some people.

The Product Owner role in agile is a big job. And very important. Many say it can't be filled by just one person because no one has all the necessary skills. They say you often need a team of people with diverse skills and responsibilities to do the job well. I tend to agree. Here is some food for thought:
http://blog.xebia.com/2008/05/22/scrum-the-mythical-product-owner-role/

Scrum Master
Next, someone on your team needs to understand retrospectives in depth. If you don't get what you need to know out of the above books, this one is wonderful: Agile Retrospectives: Making Good Teams Great by Esther Derby. Subscribe to Esther's blog.

I highly recommend Scrum Mastery by Geoff Watts. This is an excellent book filled with very practical and though provoking advice.

Lyssa's book, Coaching Agile Teams, is very useful, but the novice should read the others first.

Technical
Here are some more assorted topics:

Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin. And check out her sequel also: More Agile Testing.

Read Beck's TDD book, Fowler's Refactoring book, Evans' Domain Driven Design book, and Williams' Pair Programming book.

Specification By Example by Gojko Adzic should be in this list as should The Cucumber Book by Wynne and Hellesoy.

Lean
At some point, you might need to know what people mean by Lean as it applies to software. Poppendieck wrote the books on it:

Implementing Lean Software Development: From Concept to Cash
 by Mary Poppendieck


Leading Lean Software Development: Results Are not the Point by Mary Poppendieck.

To really understand lean, really and truly, read Toyota Kata by Mike Rother. This is about getting everyone in the org to make process improvement part of their daily job, to be very intentional about understanding the current and target condition, and to be very intentional about mentoring everyone about everything I just mentioned. This text will help you have a proper understanding about everything else you read about lean, all the techniques, all the metrics, all the approaches. 

Then read The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, a delightful book. We also have his Theory of Constraints (ToC) text. Goldratt is becoming a very important person to have read, at least for lean/agile consultants.

However, if you read Goldratt, you must also read The Principles of Product Development Flow by Reinertsen. Reinertsen takes exception with the over simplified or at least naïve implementations of ToC (et. al.).

ToC brings us to the kanban process which is gaining popularity. Kanban by David J Anderson is a wonderful book,but lacks specifics on how to do the metrics when the rubber meets the road. Subscribe to the kanbandev yahoo group. Anderson's Agile Management I would say is more advanced and should be read by serious agile managers or coaches. It's a good cross section of lean, pre-kanban, ToC, etc.

Rother's book Learning To See is about value stream mapping from a manufacturing perspective. I enjoyed working through it, but i'm weird that way. Most people in software development organizations won't need this.

Scale
There are books on scaling agile: Practices for Scaling Lean & Agile Development by Larman and Vodde. And Scaling Software Agility, Leffingwell.

Manage
Management 3.0 by Jurgen Appelo is the most important book for anyone leading or managing IT knowledge workers.


Dan Pink's Drive: understand autonomy, mastery and purpose.

Not sure whether to put DeMarco's Slack, Getting Past Burnout, Busywork and the Myth of Total Efficiency here or up under Lean. I have a blog post on slack.

Fin
Sadly, I cannot recommend this book, even thought I have a chapter in it: XP 2003 Proceedings.

Finally, find a local agile/lean/scrum user group to attend and make connections. I can tell you all about the ones in Atlanta and can connect you to people who know all about the ones in Ohio and Chicago and RTP, NC.

There are probably a thousand other folks with their own agile reading list. I wouldn't mind it at all if you were to post your list here or link from here to your site.

September 23, 2011

How to Engage an Agile Coach

I'm often asked by companies how they can engage me as an Agile Coach. What would you do? For how long would you be there? How long would it take? My response is always tailored given their specific context. Each situation is different. However, here's an attempt to give a very general response to that question.

In short, you can pretty much design your own ideal engagement with an Agile Coach. I'm sure there is a coach out there that will be willing work with you toward your goals or activities, whatever they are. Although some coaches only do deals of a certain size or of a certain type of work, there is generally lots of flexibility to be found.

For example, depending on what you are after and on your budget, the number of days and the frequency of involvement can vary.
  • Very limited: A day or a small number of days
  • Regular or periodic: A day or three each iteration
  • Full time but temporary: like 1 to 6 months
  • Full time permanent: unbounded
A single small team that just wants some outside eyes once, or once in a while, can get help with a small budget. Involving the coach with more teams and more people typically means more days are needed to accomplish your improvement or transformation goals. An organization looking for coaching for many large non-collocated teams is a much larger deal.

The engagement can be just as simple as "hey, I think we're doing pretty good, but we'd like to have a fresh set of eyes to point out what we're overlooking." That could lead to any number of recommendations that the team is free to tackle on their own. Or that could lead to an additional engagement designed to address some specific issues. Or an engagement can be as broad as be here every day and work with us for three months.

As for the type of work that a coach may do for you, the work of the coach may be in the form of training and workshops, mentoring, coaching, consulting/advising, or getting his hands dirty.

Here are some examples of what you might engage a coach to help you with. This is not an exhaustive list.
  • Limiting WIP and setting limits
  • Using Kanban and Lean metrics
  • Eliminating delay, prioritizing work via cost of delay, and improving flow
  • A3 problem solving
  • Demonstrate many retrospective techniques, lead retrospectives, mentor others as they use these techniques
  • Spotting and removing impediments and managing risks
  • Creating and sizing / estimating the release backlog, using velocity
  • Identifying the MMF set
  • Story mapping
  • Project chartering, vision casting
  • Planning and preplanning
  • Communicating
  • Using BVCs and information radiators, addressing why they are stale and not being used
  • Space and facilities
  • Pair programming, SOLID design, emergent architecture, TDD, CI, continuous deployment, etc.
  • Defining Done
  • Coding katas
  • Design patterns, refactoring, etc., for example through lunch-n-learns
  • Designing and tasking-out of stories; design review; shared task list and working as a team on each story
  • A myriad of dysfunctions
  • Issues with interpersonal relationships, working agreements, appreciation, active listening and working as a genuine team instead of as a simple working group, team accountability
  • Team goals, rewards, recognition, MBOs and other HR/management policies
  • The management role, including management influence and interference, people management
  • Scrum of scrums, multi-layer scrum and kanban
  • Working effectively with remote workers
  • Project portfolio management
  • Documentation
  • Q&A - Address the team's concerns and questions such as:
    • "How should we handle defects and minor changes in our specific context? Plan them and estimate them? Treat them as high priority and don't plan/estimate?"
    • "What should we do if we don't finish a story in the iteration?"
    • "On what day of the week should we have planning?"
    • "We're considering changing the way we do xxxxxx, what do you think?"
    • "We have work left over at the end of each iteration. What do we do?"
This list could go on and on and on. Each coach has their specialties and strengths and would come up with a somewhat different list.

Give me a call and we'll set up a time to craft an engagement of your own, suitable for your needs and your context.

July 22, 2010

If It's Painful, Do It More Often

I've worked with a number of teams who couldn't deliver. They could write code all day long for months on end, and they'd do just that. But then they'd spend a month or three shaking bugs out and still not be able to get the product into production. In many of these cases, the programmers just want to program. They don't want to or know how to do the messy task of deployment. Install and upgrade is not their core competency.

It's instinctive to cram more features into the release when it is just so hard to deliver. If you get few chances to deliver improvement, you want to cram as much in the release as possible. But that just makes it harder. More beautiful garbage to push over the goal line. This raises the inventory of unfinished work, the amount of work in process, which further delays deployment and hides the real problem.

I'm reminded of the Israelites when Moses instructed them to not save the manna that God provided from one day to the next. Do not keep an inventory of the stuff. But some of them didn’t listen and kept some of it until morning. But by then it was full of maggots and had a terrible smell. Software development with too much WIP is exactly like that.

Anyway, Lean software development reduces work in process in order to surface problems and reduce costs.


I like this illustration from page 7 in Mary Poppendieck's book, Implementing Lean Software Development. When you first look at it, your reaction might be "No! RAISE the water because there are rocks!" But the rocks are still there. Some day you are going to hit those rocks. Better to hit the rocks and deal with it in a dingy than in a yacht. Better to deal with the inability to deploy using a small release than a big one. It's better to lower the inventory, surface the issues and work to resolve them. Don't leave them there, lingering.

In eXtreme Programming we say that if is something is painful, do it more often. What we mean is that we should not avoiding dealing with problems. Solve them right away.