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…
Original Question
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.
I’m a Certified Scrum Coach and I know quite a few CST’s. Many of them offer training and coaching as part of their services. However, the typical client interaction, either with public classes or private training engagements, for many of them is as follows:
- Deliver a 2-day CSM class to a group of mostly client team members
- Rarely deliver a “talk to leadership” as part of the engagement, as theirs is more of a team-centric play…
Then they move off on their merry way. One of the “tag lines” of the Scrum Alliance is “Transforming the world of work”; so many CST’s get a sense of accomplishment at this point—feeling that the world of work has been, well…transformed.
There are two questions that I get more than any others as I travel around sharing on agile topics:
- How does agile work with distributed teams?
- How can agile deal with fixed price, fixed scope contracts?
And these questions are usually not simply questions. They’re thrown down as “gauntlets” that defy agilities promises. Often they are prefaced with – “Hey Bob, but in the real world…”
In our latest Meta-Cast, Josh and I went through a couple of questions from the audience. One of the questions surrounded what to measure for individual developers. To be honest, I was taken aback by the question.
You see, I’ve been preaching for years that when you move to agile metrics, you want to do four things:
(One) Move from individual team member metrics to a more holistic, whole-team view.
(Two) Move from measuring functional teams, for example test team progress, again towards holistic, executing agile team view.
I read a recent article/blog post by Steve Johnson where he made the case for something he calls “market stories”. Here’s a snippet from the post:
Lately I’ve been talking to people about “market stories.” Combined with personas, market stories describe the market problem on an emotional level, before you break it down into product stories and user stories and tasks. They inspire our internal teams to want to help customers as people, not just as buyers.
For example: “My father wandered away from home and we can’t find him.”
