Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
I’ve just returned from my first trip to China. I attended the TiD 2014 Conference, which was a consolidation of 3 specific conferences:
It’s the first year for the conference’s to be united in this way. For example, this was the first year for AgileChina, but the third or fourth year for ChinaTest.
There's an interesting website called Zimbio that runs a variety of fun surveys. I just filled in a Dr. Seuss character survey to see which character I most resemble. The returns are in and...tada...I am closest to:
You're the eternal voice of conscience among your group of friends, a wise worrywart with a soft spot for rules. You can be a bit grumpy at times, but you know you're often the only thing standing between order and all-out chaos. The world would really be a safer, happier place if people just listened to you.
Now if only I knew the Fish well enough to resemble that remark :-)
Stay agile my friends,
Bob.
I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.
My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.
I’m wondering if you think this post will be about the Scaled Agile Framework or SAFe? Well, it’s not. Before there was SAFe, there was good old-fashioned “safety” from an agile team perspective. And that’s where I want to go in this piece. So just a warning that no scaling will be discussed :-)
I often advise teams and organizations that are contemplating “going Agile” to consider safety as a factor when running their retrospectives. I share the “Galen-rule” around not inviting or having “managers” in the teams’ retrospective.
I was once working with a peer agile coach and we were discussing the role of the coach within agile teams. His view was that it was as a “soft, encouraging, influencing” role. That at its core agility is about the team. And the team in this sense is…self-directed.
He also emphasized that taking a more direct or prescriptive approach in our coaching would be anathema to good agile practices. That it was draconian and dogmatic.
He was actually a leader of this firms coaching team, so he had tremendous influence over a team of ten or so agile coaches. I was one of them and I sometimes struggled with his view and approach.
I came across a wonderful post about changing the daily stand-up meeting. It aligned incredibly well with how my own thinking has evolved of late. It’s by Cheryl Hammond from Northwest cadence. She makes some points around reframing the questions and/or focus of the daily standup meeting.
While I don’t agree with the entire premise of her recommendation, she did make me think some more about it and most of what she said aligned with my own evolving position.
I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…
I have a serious case of "I want to get back to JIRA Agile".
My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.
Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.
Acceptance Criteria:
- Total backlog story points stays true
- Velocity of previous sprint stays true (commitment is reflected accurately)
- it's not adding a huge amount of overhead on the ScrumMaster or the person doing it
- It doesn't need a custom app for doing this
Looking forward to your feedback!
Recently a young engineer stopped me after a class I shared at a national conference and was asking questions. The context in this case was this:
We were talking about the importance of having “dynamic” Sprint Reviews that engaged the organizations stakeholders and customers. How showing “working code” was important for the team to show progress towards their Sprint Goals and commitments.
In this particular case, the client organization was delivering more API level software to their internal customers. They were being asked for system-level functionality in some communications equipment and would implement low-level code to meet the requests. They would expose the User Stories functionality via API calls.
Last week I attended a 4-day Scaled Agile Framework class with a result of sitting for my SAFe Program Consultant (SPC) test. A few days after the class, I received an email telling me I passed the exam. I am now a proud and newly minted SPC. This enables me to teach several SAFe courses, to kick-off and coach Agile Release Trains (PSI’s), and to generally coach organizations that are adopting SAFe.
But to be honest, I’m still digesting SAFe. It’s not that I’m having trouble with the concepts or approaches. It’s more so that I’m having a challenge fitting them into my own experience in a useful way. You see much of what I learned in the class I’ve been using and doing for a long time in my own agile journey. But I’ve couched those techniques under Scrum of Scrums for agile scaling—and with fairly good success.
In the late 1970’s I worked on an assembly line at Burnham Corporation in Lancaster, PA. This was after I separated from a stint in the US Army and during my tenure pursuing a BS degree in Computer Science.
Believe it or not, I was a “Boiler Maker” at Burnham. I was a member of an assembly line that assembled boilers from parts manufactured in the plant.
I know what you’re thinking. At last, Bob has “lost it”. He’s regressed back to the early roots of his working career, which has nothing to do with his focus today. He’s now become an “old man” telling “old man stories”.
Well I will admit that I’m not as young as I used to be, but I’ve been thinking a lot about this job recently and the similarities or lessons there from an agile perspective. I hope I can connect the dots sufficiently for it to make sense to you too.
