This site uses cookies to improve your experience. To help us insure we adhere to various privacy regulations, please select your country/region of residence. If you do not select a country, we will assume you are from the United States. Select your Cookie Settings or view our Privacy Policy and Terms of Use.
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Used for the proper function of the website
Used for monitoring website traffic and interactions
Cookie Settings
Cookies and similar technologies are used on this website for proper function of the website, for tracking performance analytics and for marketing purposes. We and some of our third-party providers may use cookie data for various purposes. Please review the cookie settings below and choose your preference.
Strictly Necessary: Used for the proper function of the website
Performance/Analytics: Used for monitoring website traffic and interactions
The last couple posts have focused on teams, but I haven't addressed a basic question; What is a Team? I ran cross-country in college, so I was on the team, but was it really a team? On days we had meets, it was really everyone for themselves out their on the course. Once we left the starting line, I would see little of my other teammates until we all finished the race.
Team in front of Computer Code, generated by DALL-E 2 What is the right size for a team? Can it be too big or too small? I worked with a team once that had 3 developers. They spent most their time mob programming in front of a 42 inch monitor, taking turns at the keyboard. They didn't need to do traditional stand-ups because they were swarming around one thing at a time.
I've been reflecting on some of the agile transformations I've been involved in over the past few years. In some cases, I see some real progress made. Other times it seems like just re-arranging the deck chairs on the Titanic. An organization follows some recipe, but they don't get the results. Why? I was working with a large financial institution. They had adopted the "Spotify Model" (yes I know, it's not a real thing) and after that they adopted another scaling framework.
I was doing some research last weekend on Holacracy for a course I’m developing for University of California - Irvine Extension. I have been teaching for them for about 8 years now and I’m helping update their agile class offering. Holacracy really turns the industrial revolution style of organization on its head. Rather than leadership making the decisions for the workers to execute, the decision making is really pushed down to the people doing the work.
As a coach, I've seen many Sprint Planning sessions. Some are more effective than others. When it comes to planning, the military has a long history and we can learn a few things from them. Plans are worthless, but planning is everything - Dwight Eisenhower I have always interpreted the meaning behind this quote by Eisenhower to mean that through the act of planning, we gain a shared understanding of what we are attempting to do; the plan itself may change, but the goal won't The military talks
I was in the Moab, Utah area last weekend and got some mountain biking in. I haven't spent a lot of time mountain biking this year so I was a bit rusty. By the second day I was starting to get my rhythm but it took a little time. Just like mountain biking, our agile skills can get rusty. I ran a Lean Coffee last week and before it I read a couple articles because I hadn't done a Lean Coffee in a while and wanted to make sure I didn't miss anything.
In general, I prefer having fully co-located teams but I've been working with a number of organizations that use off-shoring as part of their delivery model. Some have the right approach, others are missing the mark. When one organization I worked with decided to move to a Scrum framework, they were also setting up an off-shore model with developers in India.
Guest post by Dr. Mik Kersten While “technical debt” is a term that’s frequently used by technologists, the implication and understanding of it tends to be opaque to the business until it’s too late - just look at how Nokia lost the mobile market that it helped create. The business and finance side of Nokia had the usual tools for assessing financial risks - but why do we not have an equivalent tool for the operational or existential risks when the debts come from the more intangible investment
A long-time colleague and friend, Dave Prior, interviewed me at Agile2018 about my presentation on being an agile coach at Toyota. You can find it here.
I'm on my way home after spending the week at Agile2018. It's been a great conference. I reconnected with old friends, met some new ones, and attended some great presentations. Monday's keynote was Dom Price (@domprice) from Atlassian. He shared how Atlassian tracked team health via their playbook. One interesting statistic he shared was that 78% of people don't trust their team mates.
I had an interesting conversation with one of my Product Owners this week. She thought that over time, planning poker values feel prey to Regression toward the Mean because human nature was such that people didn’t want to stand out and therefore tried to give estimates in line with what they thought others would. I countered by saying if people were afraid to state what they truely thought the value should be, there is probably a psychological safety issue going on.
I am still reading Daniel Kahneman's Thinking, Fast and Slow , and I came across an interesting quote People can maintain an unshakable faith in any proposition, however absurd, when they are sustained by a community of like-minded believers. He used the example of stock traders, who think they are successful in picking stocks even though evidence points otherwise.
I'm working on the book Thinking, Fast and Slow by Daniel Kahneman, who won the Nobel Prize in Economics. As you might guess, the book is about how the brain works, based on years of research. He talks about the mind as two systems, the first being fast and intuitive and the second being more deliberate. One of the ideas he discussing is that of Priming.
I recently completed the book Team of Teams by Stanley McChrystal , a retired Army General and former commander of the Joint Special Operations Task Force, operating in Iraq. It's the story of how he transformed that command in order to more effectively execute their mission. The book explores the ideas of complicated and complex. I kept thinking about the Cynefin framework , though McChrystal does not specifically mention it in the book.
I have been exploring techniques to help my Scrum teams become more effective and one of the techniques I've been looking at is Crew Resource Management (CRM). CRM came about because of a number of airplane crashes in the 70s that were attributed to human error. More recently, it is cited as one of the reasons there were no causalities in the US Air flight 1549 (Miracle on the Hudson).
I had an interesting experience recently. I was working with a team as they went thru their sprint planning. They had figured out their capacity based on yesterday's weather and their average amount of interrupt. The product owner suggested the sprint goal and they started picking stories based on the goal. They reached the point where one more story met the sprint goal, but put them over their estimated capacity.
I am speaking this week at the Projects to the Point (P2P) conference in Cairo, Egypt. The focus of the conference is the book "How Successful Organizations Implement Change" and the speakers (myself included) each wrote one of the chapters of the book by the same title. We have an interesting approach for implementing change where I'm working, a technique call Nemawashi.
The PMI Conference was held this past weekend in Chicago. They've changed the format a bit and even changed the name to reflect the changes. When I first started attending almost 20 years ago, it was the PMI Symposium, then Global Congress and now the PMI Conference. They had 3 different keynote speakers (though I only saw 2 of them), one each day. On Saturday, the speaker was Sir Tim Berners-Lee , the person that developed the technology that made the world wide web possible, specifically hyper
One of the things we talk about at work is eliminating group think and an approach to do this is using red teaming. For those not familiar with the term, red team comes from the military and originally stood for a team that represented the opposition. It has since expanded to include any team that might challenge the status quo.aka, group think. So how does this apply to the agile world?
I’m working on a new assignment as part of an agile coaching team leading a transformation at a large organization. One of my fellow coaches is also a former Navy officer. We’ve had a number of conversations about how many of the techniques developed by the military can be applied to make any team a high-performing one. One particular tool is debriefing.
I was flying home from a client visit last week at the airport getting ready to board the plane when the gate agent announced that the flight was gonna be delayed by ten minutes due to some unspecified mechanical issue. Ten minutes later they announcement another ten minute delay. They did this two more times. So what was going on? Did the airlines not want to admit upfront that they had a 40 minute delay so they fed the delays to us ten minutes at a time?
I started something new in February, a bullet journal. I've played with different tools to help me keep organized and remember stuff, and this is my latest. I went back to using paper over electronic tools for notes over a year ago based on research that showed you remembered things better when you took notes the old fashion way. Even then, I wasn't sure of the best approach.
I’m making my way through the Tim Ferris' book Tools of Titans. It’s well over 600 pages but it has a lot of useful, interesting advice, though I'll admit some of it is a bit out there. He breaks the book up into three areas; Healthy, Wealthy, and Wise. The book is really just a summary of podcasts done over the years with some other advice added in.
Agile is about delivering value, so it is important to understand the value you are delivering within an iteration or release. However, I seen many teams that focus on how many story points they deliver but not really thinking about the value of those story points. So are there ways to measure value? The answer is, of course there is. One way would be to use the Planning Poker approach, but instead of estimating the effort for each story you can estimate the value of the story.
I ran an exercise at the beginning of a new project last week; Empathy Mapping. This is part of an overall approach of using Design Thinking along with agile development. The idea to empathy mapping is to get to understand your users. Per the diagram below, you want to get an understanding of what your user thinks, says, feels, and does (though I have seen other examples that are slightly different than this).
I'm currently reading the book Design the Life You Love by Ayse Birsel. The book takes a look at Design Thinking and applying it to your own life. It is based on the success that the author has had as a product designer. The book takes you through a four-step process; Deconstruction, Point of View, Reconstruction, and Expression. She uses examples from her own design career to help illustrate the steps of the process.
I heard the term "Ready Ready" being used at work last week. I've heard of "Done Done" but this was a new one on me. I remember the first time I heard the concept of done done. When a developer finishes coding, the story is done but not done done. There are a number of other steps that have to be completed before it is really done, that is done done.
Empathy is an important attribute in Design Thinking. In order to solve our customer's problems, we really need to understand them. We need to walk in their shoes. But there's a limit to how far we can take this. We can spend hours talking to an astronaut, but we will never truly understand what it's like to walk in space. Agile has this idea of the Product Owner, but you don't see much written in agile about empathy.
By LibertyGroup25 (Own work) Henry Ford pioneered many of the ideas that are now commonplace in business, including ideas used in Design Thinking. He has been quoted as saying "If you ask people what they want, it would be a faster horse." This hits on the design thinking principle of divergence. You need to understand what problem you are solving before coming up with a solution.
Over the past weekend I went ice climbing with my son. He is a pretty serious climber and I've picked it up because of him, but neither of us have ever ice climbed before. We went to a place near Cedar Falls Iowa that ices down a grain silo. It's really different from the sport climbing we've done, but it was fun and by the end of the climbing day, I was able to make it to the top of the silo.
I haven't had much of a chance to write any posts lately. I've been on a project that has left me little time for other things, but on this Sunday I decided to take a step back. There was a learning in Daniel Pink's The Adventures of Johnny Bunko ; "persistence triumphs talent." I had a boss that taught me this early in my consulting career, that putting in your 40 hours of billable time wasn't enough.
This is part 1 of a 12 part series on the Principles of agile I've been working on a big project and as the project has grown, I've been thinking about how Agile is supposed to work and how my project is following (or in some cases not following) the principles that are part of agile. For this first article, I'm going to talk about Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This is part 2 of a 12 part series on the Principles of Agile Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Another challenge for people new to agile is this idea about welcoming change late in the project. It's not that they don't expect changes, it's the approach taken to deal with it.
Business people and developers must work together daily throughout the project. One of the challenges I often face when I start working with a new client that has not been following agile is the amount of time expected from their business people. Their approach has always been that the business people meet with business analyst (BA), tell them what they want, and come back 9 months later to see what got built.
Yesterday was the first full day of Agile2014. In general it was a pretty good day. The original keynote speaker, Aneesh Chopra, apparently had to cancel. His replacement, Sam Guckenheimer, provided an overview of Microsoft's journey to agile. It was an ok case study with some interesting information, but it wasn't a motivational keynote to get us all charged up.
Three of my favorite presentations at Agile2014 were on soft skills; Diana Larsen’s Best Job Ever , Lyssa Adkin’s Facilitating Intense Conversations , and Jean Tabaka/Em Campbell-Pretty’s Creating Agile Tribes Diana Larsen was the keynote presenter on Wednesday. After a bit of dancing, she got to the presentation. She had three main points Do Work you Love to Do Work With Purpose Take Care of you Tribe The message was that we don’t have to do a job we hate.
A number of themes surfaced during Agile2014. One of the big themes was scaling agile. There were a number of presentations on the SAFe model , Discipled Agile (DAD) and the new framework by Jeff Sutherland. There was also a lot of discussion on how Spotify scaled agile (be sure to download the paper). I appreciated the opportunity to hear about DAD from the creators, Scott Ambler and Mark Lines.
I recently had the opportunity to hear Tom Peters speak and I have to say that even at the age of 71, he still has a lot of energy and passion. He began the talk with his experience coming out of college with an engineering degree. He found the math and science classes did little to prepare him for the real world, the people part of the equation, or the “all important last 99%” of being successful.
I started reading the book Decisive by Chip & Dan Heath. They have a couple other books I've read, including Switch and Made to Stick , so I thought I'd give this a try. I'm only about a quarter through the book, but so far, I am enjoying it. It's easy to read and has some good examples to support the ideas. The book is about how to make better decisions.
There's an interesting decision making technique that I came across in the book Decisive. It's called 10/10/10. The technique was developed by Suzy Welch. She has a book by the same name. The idea is to think about how you will feel about a decision in 10 minutes, 10 months, and 10 years. The idea being discussed in Decisive is how to avoid short-term emotion when making a decision.
I have a customer with a challenge. We've been working on an application and finished our first release. The business folks looked at it and came up with a list of "must-have's" they want before going live. The IT folks are pushing back, trying to keep additional work to a minimum before going to production. They even threw out the phrase "minimal viable product" or MVP as a way say what's the least that can be done.
When I was young, I had a riding lawn mower. We had a big yard out in the suburbs and the riding mower made the job quicker. Today I live closer to downtown in a house with a smaller yard. I’m currently using an old fashion reel mower…no motor, just foot power to make it work. For the yard I have, it’s all I need. With all the technology around us, it’s easy to get caught up in the latest thing.
When I first learned Scrum , the idea was to have 30-day (4 week) iterations with a demo at the end of each iteration. Today I see teams that have iterations from 1 to 4 weeks, or in the case of Kanban, no iterations at all. So the question is, how often should there be a demo? I’m a believer of getting sign off on a user story once it's done. This usually comes from the person who wrote it, who may be a proxy to the product owner.
I’ve come across a number of articles lately that have talked about the importance of a good morning routine (like this one ), so I have been trying to practice some of these techniques. One practice is to start the day with meditation, not checking any electronic devices. I'll admit, sometimes when I'm working from home I'll turn on the TV while making my morning coffee before heading up to the office, but I don't start responding to email first thing in the morning.
124
124
Input your email to sign up, or if you already have an account, log in here!
Enter your email address to reset your password. A temporary password will be e‑mailed to you.
We organize all of the trending information in your field so you don't have to. Join 100,000+ users and stay up to date on the latest articles your peers are reading.
You know about us, now we want to get to know you!
Let's personalize your content
Let's get even more personalized
We recognize your account from another site in our network, please click 'Send Email' below to continue with verifying your account and setting a password.
Let's personalize your content