You may be smart. You may be intelligent. You may be creative. Yet to really achieve something meaningful, to make a real change, you need to do what the title suggests.
I like words and these three did something to me. There are other good words to describe this but these three are special. For me.
Which Estimation Units Should Your Teams Use For Work Items?
Why estimate in the first place?
At the feature level, you want estimates so you can figure ROI (Return On Investment), so the business and product owners can prioritize one feature against another
At the roadmap & backlog level, most organizations want to be able to forecast, be it at the feature level or release level, so you need to be able to understand what is your organization’s capacity, and translate it into plans with dates and deliverables, milestones etc.
At the finer-grained, work-item level (typically User Story), you want to help teams understand their capacity so they can take on the right amount. In particular in teams that use a frequent planning cadence, such as that prescribed by Scrum
Still at the team level, team members setting expectations on the amount of work they plan to complete can surprise themselves, learn, and improve.
At the team level, you want to understand whether a work item is small enough, might want teams to discuss estimates as part of creating a common understanding about work and align their views
Being mindful of the teaching mindset
I wear many hats at AgileSparks – what you might call a T-Shaped sparkie… Every week I can find myself wearing the consultant hat, the marketer hat, the thought leader hat, the trainer hat, the conference speaker hat, the head of business in the United States hat and probably a few more that I’m forgetting. Switching hats requires a context switch which we know is tough but also requires a mindset switch.
Specifically, what I found over the years is that going into a teaching mindset is something I need to pay some extra attention to. This goes beyond making sure I’m comfortable with the materials I’m going to deliver, reviewing the facilitator’s guide, etc.
Jira Atlassian is a great ALM tool for managing your Agile environment. It provides a friendly work space for Agile teams and has some informative out-of-the-box reports that allow teams to easily apply root cause analysis.
At the program level, there are several easy ways to achieve aggregated data reports and epic progress boards. The relatively new Jira portfolio also has some interesting features that enable larger organizations to manage their program, including shared planning, shared releases, progress, and mitigation plans.
Visiting many organizations that use Jira as their main tool for their Agile environment, I decided to summarize 5 common pitfalls it is best to avoid.
As a coach, I’ve had several opportunities to be involved in the process of big organizations moving from waterfall to agile. You usually start with frowning faces, people coming to meetings reluctantly, armed with a load of cynicism and skepticism. Then after some time, something magical happens – things change to the better. Spring has arrived!
During those first months, at the beginning of the implementation, times are hard. People are struggling. And very soon you start to hear complaints and people telling you how great it was before all this. Before all this agile. When design documents were design documents. When they had time to work. Suddenly the past becomes a lost haven. In training, in coaching sessions, you hear people reminiscing about some glorious past.
The key to addressing these issues is to find out how exactly was it at those times.
It is a slightly modified version of Henrik Kniberg’s Kanban Kick-Start Example that he graciously shared using a creative commons license. Why do we need a marketing version you ask? Because we find that people connect better to examples in their own domain so talking about code and development doesn’t really work well with marketers… Feel free to take this one and adapt it for your use and share alike! (Here’s a PowerPoint version you can edit)
“If they self-organize, what is our role as team leads?”
This is one tough question my managers asked me when I proposed we give eXtreme Programming a try. At the time, this question made me feel very uneasy, and I had a hard time providing some good answers. 15 years later, I think I finally have finally come to terms with the tough issue of management and self-organization.
There is this thing.
It’s coming up again and again.
I would say it is the root of all evil.
At least some of it.
I am referring to the need of many software development managers to make sure all their employees are fully utilized. It usually surfaces when you start talking about real team work or about agile execution.
Having all your employees fully utilized is not a bad thing for itself. It is just not the goal. The goal is to get software development done. The problem starts when “people fully utilized” gets in the way of getting software development done.
The more we meet software development organizations, the more we see how Jira, the most popular ALM tool out there, is being misused. Abusing the tool is quite easy actually… Paraphrasing Tolstoy’s words from Anna Karenina, “Good Jira implementations are all alike but unhappy implementations are all unhappy in their own way”. (In AgileSparks we keep a warm place for the classics). We have seen many cases where the abuse of the tool caused frustrations and inconsistencies with the Agile mindset that put at risk the ability to benefit from Agile practices adopted by the organization.
The subject of my talk today was “Introduction to Lean/Agile scaling approaches” where talked about why scaling approaches are necessary and when to actually try to de-scale as well as gave a very brief introduction to a couple of the key frameworks we typically use – SAFe, Large Scale Scrum, Spotify’s approach, Connected kanbans. I then finished with some decision criteria questions to ask yourself as you’re starting this journey.
Request for additional information and prices