- Agile Leadership Development
- Product Owner
Tip 1: Use the three jobs to clarify responsibilities in the organization.
For example, the job of Creating Clarity has an overlap between the role of the Product Owner on a Scrum team. Which responsibilities belong to management and which belong to the Product Owner? You can use the elements in the Agile Management Canvas, as well as your own elements. An example list for the responsibilities discussion might include:
- Purpose and Vision
- Customer Segmentation
- Strategy Mapping
- Success Metrics/ObjectivesProduct Backlog PrioritizationProduct Backlog Decomposition
Remember that the three principles of Agile management are:
- Move authority to where the work is being done
- Be mindful of complex systems
- Create safety and engagement
Given those principles and the context for your team, how might you divide the responsibilities? Let us know in the comments below.
Download Peter’s Three Jobs of Agile Management PDF for an infographic of the three jobs to help in your Agile management journey.
The history of lean and kanban is a challenge to boil down, so inevitably, I know there are aspects that are missing here. The title says “short” because, while there is a lot of information here, it is short in terms of how more is out there! Additionally, there are often disagreements on certain aspects and points around the history, and we’ve sourced the various elements included in this outline. A key part of understanding kanban is going beyond the principles and practices, to understand what is behind it work. The history points us to a critical key.
1920s: Sakichi Toyoda starts Automatic Loom Works, selling sophisticated automatic looms based on his years of inventing and improving looms. One invention was a mechanism that stopped the loom when a thread broke. This evolved into a key pillar in the Toyota Production Read More
In the past couple of months, I’ve been an instructor for numerous virtual Agile classes. The outcomes are outstanding. I’ve discovered that the people who get the most out of training do these 5 things. Here are some key tips to maximize learning in a virtual environment.
- Do the pre-work.
Any reading, videos, or other material provided by your instructor to view before class, take the time to go through it carefully. Even though many instructors will cover some of the same points in class, we know that the brain requires repetition to learn – this is particularly true for things that may be very new for you where your existing “patterns” may not always apply.
- Be an engaged and active learner.
Choose a class that is interactive and uses virtual tools that allow you to work in breakout groups, have discussions, interact on a virtual whiteboard, etc. Be an active participant if you want to learn. We learn much more by doing or discussing than we ever do from hearing or listening.
- Take breaks, stand up, and move around.
Practice self-care. Even during class, get up, stretch, and move. Sitting for long periods is hard on you and doesn’t put your brain in the most receptive mode. On breaks, don’t just check your phone or emails – move around, step outside if you can, maybe do a few jumping jacks.
- Don’t multitask or have lots of programs running on your computer.
Close extraneous windows on your PC or laptop. Not only does multitasking hinder your learning, but having too many things running can cause performance problems on your machine. Some of the new tools like Zoom and Miro or Mural are amazing but can take up significant machine capacity. It’s also a good idea to reboot your machine before a class to make sure everything is running optimally.
- Remember that classes are just the start of the journey.
Connect with classmates and the instructor to continue discussions following the course. Many times, classmates are a great source of networking in the future. Reviewing key ideas from class sometime in the first couple of days after class helps cement concepts in your brain. Most courses come with a list of references, or other suggested reading – check those out and continue the learning process.
We’re all in a difficult time right now as we deal with the pandemic, but happily, learning is something we can still do effectively. If you have available time, now is a great time to consider a class. Choose your providers wisely and then enjoy being immersed in new ideas and ways of doing things.
The kanban principles we use and I mention in What is Kanban? are fairly straightforward, yet often ignored in organizations who say they are doing kanban. I want to dig into a bit more depth on each of the principles, for those are are less familiar with them (or perhaps even for some that are).
Visualize the Flow
‘Visualizing the flow of work is about being able to see all the process steps needed to deliver your work. This is accomplished by using cards to represent work and columns to represent steps, from start to finish. Read More
This is a common question, since Kanban can have several word uses and meanings in the agile space. The term gets thrown around a lot, making it even more confusing. In order to understand Kanban and where it comes from, let’s start with some basic definitions and the foundations. We start with the basics, because there is often confusion around what kanban is.
Simple definitions of kanban:
- a signboard or billboard in Japanese
- a just-in-time method of inventory control, originally developed in Japanese automobile factories
- a Japanese lean manufacturing system in which the supply of components is regulated through the use of an instruction card sent along the production line
- an agile approach or framework
I hear these requests all the time. “What are the best agile metrics?”, “How can we measure an agile team?” and “I know we can’t just measure agile. . . but, what should be on an “organizational agility checklist?”
There are so many places you can go with these questions and there are even various companies selling ways to measure agile organizations and agile teams. When someone asks me about agility checklists or agile metrics, I tend to start with a few core themes of elements. I use these themes to have conversations with the people who want the measurements and the people who will be measured (before anyone starts using them).
Basic agile stuff: Whatever basic agile stuff might be important (experiments, improving via retros, delivering features, etc.). Since this is the one people focus on the most, you can find more out there on this one if you don’t already have ideas. A lot of basic agile measurement-checklist items tend to be focused on outputs, which are okay, but see the section below on outcomes and outputs.
Transparency: I always look to include some items that focus on transparency. I find that transparency is a great equalizer to best practices (don’t limit yourself with best practices) – when done right, they go well together. Elements like “The team is transparent with leadership about the impact of sprint interruptions” and “the team is transparent with each other about internal team challenges” are good starting points to discuss these ideas and figure out how you will know.
Balance: Balance is key. I want items for the leaders as well. “Leaders reactions to changes help to increase trust with the team” (can be a fun one to discuss!). I want items that are clear, yet have some variability in them (is that even possible?). I like to make them simple enough that people can agree that doing the opposite would be a bad thing. Balance is critical for checklists and metrics because it allows you to look at multiple focal points that impact an outcome.
Outcomes and outputs: I do see value in both outcomes and outputs. An outcome is an end goal that drives your organization vs an output that can (but does not always) drive outcomes. An output might be lines of code per day (blah) or features delivered in a sprint (I don’t dislike this one as long as it is balanced with others). These might be useful to measure as an output, but the outcomes would be the results of those outputs. We want to look at the outcomes to know if the outputs are achieve the results we need as an organization. This is another reason you need balance.
For example, if I look at the output of features delivered in a sprint as a potential factor that helps us achieve the business driving outcome of 5% new customer growth. There may be many factors that help us achieve this outcome and the output of delivering features in a sprint (specific to that outcome of course) is just one of them.
The features in the sprint may have been focused on a new marketing campaign or features to make it easier to get referrals, however that does not mean those achieved the outcome of 5% new customer growth. Even if you increased your referrals by 300% (another output), that does not mean you will have 5% new customer growth. Another output that might impact that outcome might be measured as percentage of customers followed-up with after initial sale. We could measure that and track it, but like the increase in referrals, just because we follow-up with 100% of customers does NOT mean that we will hit out outcome of 5% new customer growth. (Note that even the outcome we are talking about still needs more work because we don’t just want new customers, we want new customers that we retain for as long or longer than current customers – assuming we are happening with out current customer retainment. Just realize you can always peel the onion more.)
Inspection and Adaptation: The last element I’ll mention is inspection and adaptation. I like to look for ways to add agile checklist items or agile metrics that are focused on improving the checklist or metrics. This might sound a funny at first, but inspect and adapt! You know that there will be change, so build that into whatever you are creating from the start. Adding elements that are aimed at improving the agile metrics over time (adding, changing, deleting items) helps acknowledge from the beginning that there is no perfect answer.
In summary, look at the problems agile checklists or agile metrics might create and look at the concerns you might have with them, then find ways to hack the checklist against those problems.
How long should your sprints be? Generally, 1-2 weeks, with a preference towards a shorter sprint.
But that’s not what I’m writing about today. I want to introduce you to the magic of 1-day sprints. Read More
It’s been a whirlwind for many of us as we’ve adapted to the current work conditions – that’s equally true for us as Scrum Trainers at Agile for All! While many of us have extensive experience in the virtual realm, this is the first time that we’ve been able to deliver the CSM and CSPO in this way.
I spent a week of intensive work transforming my Certified ScrumMaster (CSM) course so that it could be presented in an interactive and effective way. I’ve now facilitated that class 3 times with great results and here are my top 3 learnings about virtual classes. Read More