A colleague of mine, Robin Dymond, posted this great video about Scrum and healthcare.gov on Youtube. It is a fantastic summary of Scrum and is well worth the 20 minutes to watch.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
Ten Most Commented Upon Agile Advice Articles
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
Plans for the Future – Five Top Ideas for Series
Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe. (Thanks to Gerry Kirk for bringing this article to my attention!)
As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK. I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights. I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption. I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.
I’ve proposed a session called “Agile Manifesto and Enterprise – Rant and Rave” for the Toronto Agile Community’s conference “Toronto Agile and Software“. The session is based loosely on my earlier article “The Agile Framework: Agile Values and Principles, The Agile Toolkit, The Agile Organization“, as well as some of the things that I do in the 2nd day of my Certified Scrum Master training session. If you are thinking of coming to the conference, I would greatly appreciate your votes or feedback on my session proposal!
Another fantastic article by Mike Caspar: Sprint Retrospective vs. Lessons Learned (a Generalization)
Consider reviewing these differences in your environment to determine if you are getting benefit from your Sprint Retrospectives and following their intent.
Thanks to my good friend Deborah Hartmann Preuss for showing me this great tool: Retr-O-Mat – Inspiration (and Plans) for Agile Retrospectives. It’s a great way of generating a plan for your retrospective if you’re feeling a lack of inspiration! Includes all five stages of a retrospective: set the stage, gather data, generate insights, decide what to do, and close the retrospective.
I just finished reading “Test-Driven Development as Pragmatic Deliberate Practice“. Fantastic article. I highly recommend it to anyone who is actively coding. It strongly reflects my understanding of TDD as a fundamental technique in any Software Development Professional’s toolkit.
“Truthfulness is the foundation of all the virtues of the world of humanity”
Many people can see some validity or value in this statement, but it may seem strange to them to incorporate this component into business practices or corporate culture. After all much of what is common practice does not reward or encourage those who choose to be truthful.
But as Bob Dylan so aptly put it, “the times they are a-changin’”.
The environment, our capacities as human beings, and our tools to interact with the world are constantly evolving and growing. Yet much of what we do today is based on assumptions about human nature arrived at hundreds or even thousands of years ago when we had less knowledge and understanding about the world and ourselves. Along with the rest of the universe we are evolving as a human species, as such it only makes sense that our higher understanding and knowledge inform our decisions and practices, so we can keep progressing forward.
OpenAgile recognizes the true nature of humanity and how it can work to create a remarkable world in every endeavour. Scientific discovery is revealing this truth about our nature as well, as the video below so wonderfully illustrates.
Be Open, Be Agile, Be Free.
One of the things that I love is how many great videos there are that show the ridiculousness of a lot of corporate behaviour. This video is a hilarious (and painful) look at one aspect: the way we treat our experts.
Of course, I don’t mean to say that we should never be sceptical. Rather, sometimes we just have acknowledge reality: there is no magic to make a red line with a green marker. The role of the expert is to clarify reality to others through their knowledge and experience.
When I am doing CSM and CSPO training, I often am faced with people who want to know how to make high-performance teams with distributed team members. They are often looking for some sort of magical solution. This is an example of not being willing to face the reality that distance makes communication slower, less effective, and less likely to happen at all.
I’m sure all of you have interesting experiences of being the expert in something and your audience pushing you to find the magical solution… share your stories in the comments please!
I was recently checking my Google Analytics for Agile Advice and the article I wrote quite a while back in 2009 about teamwork skills is even more popular than the front page of this blog! I took a look at it and made some tweaks including providing some good references for more information about each of the teamwork skills. Take a look: Seven Essential Teamwork Skills. The only hard one was to find a good article about “sharing” as a teamwork skill. If you know of one, please comment so that I can add it! I’ll even be happy to take a link to an article you have written yourself.
Another great article by Mike Caspar: Consider the ability of your Stakeholders to come to your Sprint Review or Demo before declaring it. From the article:
If you are in an environment that is struggling to get stakeholders to your review, ask yourself if you have chosen an impossible day of the week for this ceremony.
Please, for the sake of your team(s)….
When considering when your Sprint will end,
think of the ability of your stakeholders
to actually show up once in a while!
Stakeholders are people too. They don’t want to let the team down either.
Mike has great experience working with Scrum teams and I hope you read through his other articles as well.
Wired magazine has a nice little summary of personal kanban. Check it out!
If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives. I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago. Very helpful with some practical information, some great links… I strongly recommend checking it out. My only concern is that they limit the scope of retrospectives too much. I have a list of topics that I think can and should be considered in a retrospective:
This list comes from a presentation I used to include as part of my Certified ScrumMaster course. (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.) Here is a PDF version of the Retrospectives Module.
I’ve made a minor update to my article about Agile Estimation with the Planning Game to include a downloadable pdf of the article for easy printing. The downloadable version also includes a tiny bit of commentary that comes from my upcoming Agile Advice book. There are also two links added at the end of the article. One is the the wikipedia article about Planning Poker (which describes the method slightly differently), and the other is to an article I wrote a long time ago about the wideband delphi estimation method.
I just finished attending my SAFe Program Consultant (SPC) training and I wrote a review of the Scaled Agile Framework 3.0 and the SAFe Program Consultant training. I won’t quote myself here
Also, Lyssa Adkins has recently published her own review on InfoQ. I enjoyed reading it because Lyssa is so gentle, fair, and insightful. She puts a lot into connecting the Scaled Agile Framework with the Agile Manifesto and shows that there is a fantastic level of alignment between them. Her article is called “Agile Coaches’ Coach Shares Her View on SAFe“. Here’s a bit of a teaser from her article:
Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall…” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.
A surprising thing happened in that class…..
Although I don’t know him well, the few small interactions I’ve had with Peter have engendered in me a great deal of respect for him. His fundamental philosophy of Agile and organizations is courageous and principled. I found out yesterday that Peter wrote a review on the Scaled Agile Framework back in February 2014. Please check out “The Scaled Agile Framework (SAFe) – A Review“. It is interesting and insightful. Great quote:
What SAFe is Far Better At Than Most
SAFe (Scaling Agile Framework) is gaining in popularity. Ron Jeffries recently attended a SAFe training session and has written a great review. I particularly like what Ron says about the idea of being properly Agile:
SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.
SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.
Mr. Cohn has written a really fun April fool’s parody of SAFe that, given the comments, surely counts as a review as well. It’s called “Introducing the LAFABLE Process for Scaling Agile“. Although it starts on a very humorous note, the comments are quite extensive and contain lots of great discussion. Here’s an important comment from Mike Cohn about the whole concept of scaling that gives you a taste of the discussion:
I don’t think “agile at scale” is a bad word. I’ve consistently maintained that projects should be as agile as they can be but no more. A project that requires let’s say 500 people will never be as agile as one that requires 3 people. But I can’t imagine the 500 people and 3 people being competitors. And, if they are, the bigger mistake made by the 500 person project is involving the other 497 people, not the process they choose.
Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them. I like what he says in one of the comments on his blog post:
So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.
I don’t personally have any experience with SAFe so I won’t make any big claims about it either way. However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity. Is this just the Hawthorn Effect at work?
When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements. Sometimes this results in people losing their jobs. Sometimes this means people have nervous breakdowns. It can be very painful in the short term. SAFe, by it’s very name, seems to be anti-pain. That doesn’t bode well.
Here are a few other interesting links to information about the Scaled Agile Framework:
* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.