Many people really don’t like the original cartoon (See & read Pig & Chicken part 1). When I decided to do three strips on the Pig & Chicken, I knew there would be a lot of ‘concern’, but based on where I want to go, I made the decision that it had to be done. Tweet the Agile Safari Cartoon!
Project retrospectives are challenging. I spoke a bit about this in lessons learned vs. project retrospectives. You might look at a merger, acquisition, implementation of a new ERP system, or even a major upgrade of an ERP or CRM system. These are non-reoccurring events. A retrospective of this type is quite different from a typical agile retrospective, primarily because on this type of project, people will change and the project will not repeat (the definition of a project is that it is a unique endeavor). At issue here is the fact that if the people will not be the same and the project does not reoccur – then they can’t come up with actions they will apply right away based on what they learned. Ideas for change often just end up in a spreadsheet, a book shelf, or some electronic tool. A big book of “lessons learned” that sits on the shelf gathering dust does not provide much, if any, value.
The Pig & Chicken is a cartoon many in the agile community are familiar with. I know some will see it and ask why this one is being rehashed (I know this because I reviewed it with a few people, and they asked). Some will be pretty annoyed since many “strongly dislike” the cartoon (which is fine – please add your comments!). So, for anyone reading this and thinking any of those things, please read on. I want to say, “Don’t worry, I have a plan,” but only you can judge how it pans out for yourself! Tweet the Agile Safari Cartoon!
For readers who are not familiar with agile (or any agile folks who have not seen the cartoon), the ideas is that the pigs are the team (or Scrum Team). The chickens are everyone else.
I’ve been training, talking, coaching, and writing recently on the topic of commitment and realized that anytime that comes up, it reminds me of the old (seems old – but not really that old!) discussion on commitment or forecast. I still find there are many questions on this topic. It certainly has not been put to bed. The approach I like to take is to step back and ask “what is the real problem?” Is a word stopping you from succeeding or is something else causing the problem? What am I talking about? — I’m talking about when the Scrum Guide was updated to change commit to forecast.
Learning the different approaches an agile coach may take can be challenging without experiencing them. My preference when training people is to run exercises to help them experience the various approaches to agile coaching. Most recently, I had the opportunity to run one with a diverse group of people at a recent conference. We got into some amazing discussions! I also had a chance to riff back and forth with Bob Hartman, who joined me for part of the session, which created a fun dynamic!
Since getting together in-person is not always possible, this article includes visual diagrams of the agile coaching framework, to explain visually, how to walk-through the framework.
No, I don’t hate agile project management software — it can serve a purpose. At issue is if there is an actual purpose and if it is misused. Often the software stalls progress or worse, move us backwards. For any readers who are not familiar with agile or don’t work in software — the idea here is that instead of using the monitor to display some type of software tracking tool, the new scrum master just used sticky-notes and stuck them on the monitor. What is the simplest thing that works in your world?
The most common agile retrospective focus is on the sprint (or iteration) that was just completed. For most agile teams, this is the past two weeks. We have many more options for retrospectives than simply looking back on the last sprint. We can look at a specific topic, an event, use a future focus, or look at a much longer timeline. Regardless of the focus, we are aiming to learn, generate ideas, and (ideally) agree on actions to take moving forward to improve to sustain.
Have you been in a situation where no one would bring up the problem that everyone knew was “in the room?” I’d guess that everyone has been there. So often, we don’t bring up the “elephant in the room.” For anyone who has not heard of this, the elephant in the room is a saying for the real or obvious truth that is not being addressed. Given an elephant in a room would be hard to miss, when people ignore it, they are typically pretending it is not there.
I was presenting Building Antifragile Relationships and Teams at Santa Barbara Agile recently and as we worked on ideas for a conflict protocol, we started discussing the common theme of “facts vs. feelings”. I’ll point out that there was not a hard-line view in the group as to one way or another, but it came up and opened up a nice discussion on the topic.
I mentioned The Focused Conversation as a great tool you can use to help structure a conversation. Focused Conversations include four important categories of questions — objective, reflective, interpretive, and decision focused questions. The acronym ORID is sometimes used to describe The Focused Conversation.
The structure also provides a way to hear all of the voices that need to be heard within the group or team. You might even use this as part of an agile retrospective. Using the tool is another way to build antifragile relationships in teams and organizations.
We hear a lot about best practices. We talk a lot about them. Many organizations are of the opinion that if they can identify the best practice, they are set. Of course, that thinking can be limiting in a number of ways. We need to be better, not best.
Googling “best practice definition” gives you “commercial or professional procedures that are accepted or prescribed as being correct or most effective.”
Wikipedia says : “A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. In addition, a “best” practice can evolve to become better as improvements are discovered. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.”
Notice in the Wikipedia definition they add the idea that they can evolve to become better. This gets to the root of what we need to be doing.