Skip to content

Feed aggregator

The Case for and Against Estimates, Part 4

Johanna Rothman - Thu, 06/09/2016 - 22:34

When we think about the discussion about estimates and #noestimates, I have one big question:

Where do you want to spend your time?

In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)

In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off. 

In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.” 

For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)

In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean,  you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.

Here’s the way I like to think about #noestimates:

Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.

I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.

In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.

On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.

When I think in #noestimate terms, I think of showing value for the entire product.

Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.

When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.

In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.

Back when I wrote code for a living, I was not good enough to deliver in  hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.

When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.

In my work, I want to show value as early and as often as possible.  When I work with teams and managers, that’s part of my work with them.  Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.

I have found it helpful to create an order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.

The smaller the deliverable, the more often  you can get feedback and show value. I have seen these benefits from working this way:

  • The project ended earlier than we expected. That’s because we delivered “enough” to satisfy the PO/customer. (I’ve seen this many times, not just a couple of times.) If we had spent more time generating a detailed estimate, we would not have delivered as quickly.
  • We learned enough about the deliverables that we were able to do more discovery (as Ellen Gottesdiener says) as we delivered. We made the whole requirements process continuous and just in time. We did not require hour-long pre-sprint planning meetings. (Okay, that’s only happened twice. I have hope for more experiences like this.)
  • We were able to fix things before they got too large. We’d started in one direction on a feature set, realized we were headed in the wrong direction and replanned what to do and how to do it.

To me, the idea of #noestimates is tied up in small chunks of value.

#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.

The posts to now:

  • Part 1 talked about targets and order of magnitude estimates.
  • Part 2 discussed when estimates are not that helpful. I did not include bad management in this post. Managers who treat estimates as commitments are not helping anyone.
  • Part 3 is about when estimates are helpful.
  • Part 4, this post, is about #noestimates.

I’ll do a summary post, including a pointer to the original article in part 5.

Categories: Blogs

The Case for and Against Estimates, Part 3

Johanna Rothman - Thu, 06/09/2016 - 22:14

In Part 1, I discussed order-of-magnitude estimates and targets. In part 2, I said how estimates can be misused. In this part, I’ll discuss when estimation is useful. Here are several possibilities:

  • How big is this problem that we are trying to solve?
  • Where are the risks in this problem?
  • Is there something we can do to manage the risk and explain more about what we need to do?
Estimates can be useful when they help people understand the magnitude of the problem.

One of my previous Practical Product Owner students said, “We use story size to know when to swarm or mob on a story.” People tackle stories up to 5. (They use Fibonacci series for story size.) They might pair or swarm on stories starting at size 8. Even if they have a 21 (or larger) size story, they swarm on it and finish it in a couple of days, as opposed to splitting the story.

They use estimates to understand the size and complexity of the feature. (I would call their features “feature-sets,” but they like to call that one big thing a feature.)

You might not like that approach. I think it’s a fine way of not fighting with the PO to split stories. It’s also helpful to work together to solve a problem. Working together spreads knowledge throughout the team, as a team.

My experience with estimation is that it’s easy for me to not understand the magnitude of the work. We manage this problem in agile/lean by estimating together, or working together, or with timeboxing in some way.

The first time we solve a particular problem, it takes longer. The first time I worked on a control system (embedded software), I had to learn how things worked together. Where did the software interact with the hardware? What were the general risks with this kind of a product? The first time I self-published a book, everything took longer. What were the steps I needed to finish, in what order?

I worked on many control systems as a developer. Once I understood the general risks, my estimates were better. They were not sufficiently accurate until I applied the rules of deliverable-based planning. What deliverables did I need to deliver? (I delivered something at least once a week, even if it was data from what I now know is a spike.) What inch-pebbles did I need to create that deliverable?

The more I broke the work down into deliverables, the better the estimate was. The smaller the chunks, the better my estimate was. The more I broke the problem down, the more I understood what I had to do and what the risks were.

One of the things I like about agile and lean is the insistence on small chunks of value. The smaller my chunk is, the more accurate my estimate is.

Estimates can help people understand risks.

You’ll notice I talked a lot about risks in the above section. There are general project risks, such as what is driving the project? (See Manage It! or Predicting the Unpredictable, or a series I wrote a few years ago, Estimating the Unknown.) We optimize different work when we know what is driving the project. That’s the project view.

We have possible risks in many deliverables. We have the general risks: people get sick, they need to talk the duck, they multitask. But, each deliverable has its own risk.

I’ve said before software is learning, innovation. You may have done something like this project before, so you have domain expertise. But, you have probably not done this new thing here.

When I estimate, I start thinking about what I need to do, how to solve this problem. Then, I start thinking about the problems I might encounter in solving those problems.

I can’t get to the problems unless I have inch-pebbles. I am a big-picture person. I see the whole problem, possibly even the whole solution, and I skip some of the steps in my head. I estimate top-down as a start. Unless I create my inch-pebbles, I am likely to gloss over some of the risks because I start top-down.

You might not be like me. You might estimate bottom-up. You might see all the details. You might not miss any steps in solving the problem as you think about it. (I wonder about people like you: do you see the big picture at the beginning, or does it evolve for you?)

I have met some people who estimate inside out. They tell me they see part of the big picture and part of the small steps. They iterate on both parts until they see and can estimate the whole thing.

I have taught a number of estimation workshops. Most of my participants are top-down people. They see the result they want and then envision the steps to get there. I have met some small number who start bottom up. I have met two people who are inside-out. I don’t know if that’s a normal distribution, or just the people who participate in my workshops.

Estimates can help people understand possible first steps.

When people think about the first thing that can provide value, and they think about how to make that first thing small (either inch-pebbles or agile stories), they can more easily see what the first deliverable could be. They can discuss the deliverable progression (in agile with a product owner and in a more traditional life cycle with a project manager or a product manager).

I have found the discussion of deliverable progression very helpful. Many years ago, I was the lead developer for a gauge inspection system (machine vision on an assembly line). I asked the customer what he wanted to see first. “Can you see the gauge enough to give us some kind of an answer as to whether it’s a good gauge?” was his answer.

Notice he said “enough,” not “a perfect inspection.” We did a proof of concept in a couple of days. In the lab, with the right lighting, we had an algorithm that worked well enough. You might think of this as a discovery project. Based on that deliverable, we got the contract for the rest of the project. If I remember correctly, it took us close to 6 months to deliver a final system.

For that project, I acted as a cross between a project manager and what we now call a product owner. We had release criteria for the project, so I knew where we were headed. I worked with the customer to define deliverables every two weeks, after showing a demo of what we had finished every two weeks. (This was staged delivery, not agile. We worked in week-long timeboxes with demos to the customer every two weeks.)

This is in the days before we had project scheduling software. I drew PERT diagrams for the customer, showing date ranges and expected deliverables.

A few years ago, I coached a project manager. She was the Queen of the Gantt. She could make the Gantt chart do anything. I was in awe of her.

However, her projects were always late—by many months. She would work with a team. They would think it was a six-month project. She would put tasks into the Gantt that were two-, three-, and four weeks long. That’s when I understood the problem of the estimation unit. “If you measure in weeks, you’ll be off by weeks.” Her people were top-down thinkers, as I am. They glossed over some of the steps they needed to make the product work.

I explained how to do deliverable-based planning with yellow stickies. The people could generate their tasks and see their intersections and what they had to deliver. She and the team realized they didn’t have a 6-month project. They had a project of at least a year, and that was if the requirements didn’t change.

When they started thinking about estimating the bits, as opposed to a gross estimate and applying a fudge factor, they realized they had to spend much more time on estimating and that their estimate would be useful. For them, the estimation time was the exploration time. (Yes, I had suggested they do spikes instead. They didn’t like that idea. Every project has its own culture.)

How do your estimates help you?

Maybe your estimates help you in some specific way that I haven’t mentioned. If so, great.

powerlawdistributionThe problem I have with using estimates is that they are quite difficult to get right. See Pawel Brodzinski’s post, Estimation? It’s Complicated… In

In Predicting the Unpredictable, I have a chart of how my estimates work. See the Power Law Distribution: Example for Estimation. (In that book, I also have plenty of advice about how to get reasonable estimates and what to do if your estimate is wrong.)

In my measurements with my clients and over time, I no longer buy the cone of estimation. I can’t make it work for agile or incremental approaches. In my experience, my estimates are either off by hundreds of %, or I am very close. We discover how much I am off when the customer sees the first deliverable. (In Bossavit’s Leprechauns of Software Engineering, (or on leanpub) he says the cone of estimation was never correct.)

For me, deliverables are key to understanding the estimate. If, by estimating, you learn about more deliverables, maybe your estimation time is useful.

Since I use agile and lean, estimating time for me is not necessarily useful. It’s much more important to get a ranked backlog, learn if I have constraints on the project, and deliver. When I deliver, we discover: changes in requirements, that we have done enough, something. My delivery incorporates feedback. The more feedback I get, the more I can help my customer understand what is actually required and what is not required. (I often work on projects where requirements change. Maybe you don’t.)

I realized that I need a part 4, that specifically talks about noestimates and how you decide if you want to use noestimates. Enough for this post.

Categories: Blogs

What is Agile Leadership?

Agile Management Blog - VersionOne - Thu, 06/09/2016 - 14:30

What is agile leadership?Have you ever faced one of the following challenges with your agile adoption?

  • Executive teams who want you to be agile, but still require all the traditional metrics and reporting
  • Middle managers who feel threatened by agile and seem to be working against you
  • An organizational culture that seems to run counter to an agile way of working

If you are experiencing any of the issues above you are not alone. After working with hundreds of organizations and thousands of people these are the most common themes that have emerged. Rather than giving up on your agile adoption, it’s time to bring agility to your organization’s leadership team. You need agile leadership. Let’s examine why…

In any business there are two main roles; people working “in” the business and people working “on” the business. Agile methods, like Scrum, do a great job of addressing the roles and responsibilities of people “working in the business”. For example, Scrum says that we need a product owner; someone responsible for guiding the team to build the right product to meet the needs of the stakeholders. Most agile methods however, do not address the roles and responsibilities of those “working on the business” – AKA “management”.

Some agile experts have taken a stand and said that we don’t need “management”, that we should fire anyone with a leadership title. That is one view, albeit an unfortunate one. Another view is that we need people who are fully dedicated to; planning and setting a vision, building an agile culture, and supporting those doing the work.

My colleague Pete Behrens says that “agile leadership” is the glass ceiling that prevents our organizations from becoming agile. We need to break through this ceiling if we are to build truly agile organizations.

Now that we have examined why we need agile leadership, let’s define what it is…

To come up with a definition, I first looked at the values of the Agile Manifesto ( In order to be an agile leader we need to:

  • Remember that it’s all about the people (individuals and interactions)
  • Focus our efforts on delivering business value (working product)
  • Form and respect the partnership with our clients (customer collaboration)
  • Plan and be willing to react in the moment (responding to change)

I also examined some of the fundamental principles of agility:

  • Transparency – When I graduated from college I worked for a small startup. One day they called us into the conference room to let us know the company was in dire financial trouble. At this point we were so far into the red that people had to be impacted. The owners of the company felt like they were protecting us from this knowledge. Because we didn’t know the company’s financial situation, we couldn’t do anything to help them. Agile leaders work hard to be open and honest with their communication. They make sure that all needed information is out in the open and easily accessible.
  • Continual feedback – Agile leaders abhor practices like the annual performance review. Instead of bottling up feedback and delivering it all in one fell swoop. Agile leaders provide feedback in the moment where it can add the most value.
  • Inspect and adapt – Agile leaders use retrospectives to frequently pause and examine the output of the team and the way that the team works together. These retrospectives allow for everyone to get better at a more expedient pace.
  • Embrace failure – By running short low risk experiments and “failing” we learn rapidly. An agile leader sees failure as an opportunity for their teams to grow, not something that should be prevented at all costs.

Finally, there are few practices I have learned:

  • Be a servant leader – Key tenants of servant leadership include; taking care of needs not wants, building and using influence rather than abusing power, and leading by example.
  • Focus on strengths – Agile leaders get to know their team members on a deeply personal level, which allows them to know a team members strengths and weaknesses. Rather than focus on the losing battle of shoring up weaknesses, agile leaders focus on building strengths instead.
  • Be vulnerable – I used to think that emotional intelligence meant stopping our bodies natural reactions to stimuli and choosing to react in an “appropriate” way. Now, I know that stopping and bottling up emotions only leads to health problems. Agile leaders are comfortable with expressing their emotions in front of their team. They realize that “being real” leads to strong relationships and greater team intimacy.

Combining what the Agile Manifesto, Agile Principles, and my own experience; I came up with the following definition of an agile leader…

“Agile leaders are inclusive, democratic, and exhibit a greater openness to ideas and innovations. With a passion for learning, a focus on developing people, and a strong ability to define and communicate a desired vision, they possess all of the tools necessary to successfully inspire others and become an agent for change within any organization.” – Center For Agile Leadership

Would you like to meet a real life agile leader? I would like to introduce you to Joe Kirk (, CIO at the Tennessee Department of Transportation. Joe has built a truly agile organization. A few of his major accomplishments include:

  • Shifted his departments culture from one where everyone couldn’t wait to retire, to one where everyone can’t wait to complete their next sprint
  • Built out co-working spaces so that his teams can collaborate
  • Recently hosted an innovation day that produced several promising product ideas

Wondering how you can become an agile leader yourself? Or perhaps you know a leader who wishes they could be more agile?

There are a number of new offerings coming onto the market today, such as our Certified Agile Leader® program. Also, in April 2016 the Scrum Alliance announced their new Certified Agile Leadership program, which follows a similar pattern to our program. We hope that there will soon be a convergence of the two programs, since they have the same goal in mind. To learn more about becoming an agile leader please visit http://www.centerforagileleadership

The post What is Agile Leadership? appeared first on The Agile Management Blog.

Categories: Companies

WIP, Capacity, and Dirty Laundry

NetObjectives - Thu, 06/09/2016 - 13:05
A benefit of being a CIO is that you get to collect a treasure chest of war stories to share with other CIO’s.  These stories also serve a purpose:  They teach patterns to watch out for (so that if nothing else, you learn when to cringe.) One of my war stories goes like this.  Outside my glass-walled office, in plain view from my desk, is an operational dashboard that shows concurrent users, and...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Managing to Lead

Leading Agile - Mike Cottmeyer - Thu, 06/09/2016 - 12:30

Every week I have to get ready for my call with my coach and it is unlike almost everything else I do. Every other conversation I have is, if not predictable, then at least familiar territory. Not so with my coach; the conversation can quickly go somewhere unexpected and nearly always does. The discovery is usually fun and I come away feeling energized with a new perspective.

I am reminded every time I’m preparing, of the Zen Master and the teacup.  As the story goes, a successful businessman seeks wisdom from a Zen Master who then pours tea for him until it overflows and spills on his suit. The man complains, and then the master replies that his mind too is full like the teacup with all that he thinks he already knows. He is admonished and is told he must leave and not return until he can empty his mind and make room for wisdom.

Managing to Lead

I’ve known my coach for many years…almost two decades…and you might think the challenge of emptying my cup would get easier, but it doesn’t. The rituals help, and the familiarity with my coach helps, as does his natural way of bringing some sense of ease and acceptance to even the most challenging life conversations. But almost like meditating, working towards an empty cup is a shift in thinking that always feels new again.

As an agile coach, I am obliged to pay closer attention. I have empathy for the people I am working with because I know how disorienting it can feel to continually be learning something new. The skill of agility is far more than just the rituals of agile. And similarly, servant leadership in particular is more about who we are for other people than it is about management rituals like status reports. There is far more to being agile than methodology or process.

The way we learn it is completely different too. Every day is learning and all the while, every day is also important to successful team delivery. It seems like there are never any breaks in the action. It is truly challenging and so much more than the kind of learning we all did in school. It is not a matter of learning something just in order to pass a test, or learning some skill…calculus??…that I may or may not use some day. It is something we need to learn and apply while we are learning it. It is learning that matters right here, right now, every day.

“Certainty is not proof of truth.”

–  Maturana & Varela Tree of Knowledge

Some people have more of a challenge than others. Surprisingly, or maybe not so surprisingly, the more successful the person, the more often they have trouble. In my many years as an agile coach, I’ve heard countless times “that won’t work here”, only to see it in successful practice 6 months or a year later. Many of the skills of an effective servant leader fly in the face of traditional management. Seasoned managers in particular seem to have a tough time acquiring this new skill of being open to possibilities.

Before Industrialization there was craftsmanship and skill and dedication to the unique needs of each customer. With industrialization came efficiency, management and the pursuit of volume. The need for same-ness was equated with quality. The values of craftsmanship and the art of everyday skillful delivery gave way to volume, predictability and consistency.

With today’s knowledge workers, unique innovative solution-making is less about being managed for volume or velocity and more about being inspired with a clarity of vision, a great team of other craftspeople, and a deep understanding of what each customer really needs and wants. Leaders need to help create a clearing for their people to try new things, invent and feel safe doing so. It should be baked in to the teams capacity expectations.

Agility is really more of a personal, team and organizational skill than a methodology or a process. Learning about it requires learning some new distinctions. Rituals like standups, demo’s and exploratory testing are one thing, but code smells and anti-patterns are another. And we have to learn real-time through experimentation every day.

Leading knowledge workers requires very different skills than that of traditional management. Learning those skills requires a new posture to learning.

Remember when you were young and learning was energizing and fun? That is “beginner’s mind” and that is the state of having an empty cup. It is clear eyed, buoyant and curious rather than having “the answers”, and that is the state of discovery we are after. But it won’t happen without recognizing in ourselves, real-time, every day, that we need to adopt this new posture. At first it will feel uncomfortable, but with practice it will begin to feel exciting and fun and not knowing what will happen is part of the fun.

Making a transition from manager to leader means learning to see the world anew. It can feel vulnerable to no longer rely on what has worked for us in the past. We can take solace knowing that we are not the first and we are not alone. Success as a leader today means constant learning; even our coaches and mentors are all learning. The same is true when we are learning to be more agile. In many cases, it is time to empty our cup and simply become more open to the unfolding and discovery of something completely unexpected.

The post Managing to Lead appeared first on LeadingAgile.

Categories: Blogs

Agile is not magic

IceScrum - Thu, 06/09/2016 - 12:30
After years helping companies to adapt their practices and change their mindset toward agile values, a comment we hear very often is “Ok, we know that we don’t follow the recommendations… But our context is quite singular and Agile/Scrum is meant to adapt to everything, right? Thus, we adapt it to our context.”. Unfortunately, it…
Categories: Open Source

Delivering quality software with Agile

Ben Linders - Thu, 06/09/2016 - 10:32

Delivering quality software agile bits chips 2016My article on delivering quality software with Agile is featured in the first English edition of Bits&Chips, a news magazine for professionals who develop smart products and systems. A big thanks to the editorial staff and to Nieke Roos, editor-in-chief of Bits&Chips.

My article explores what agile teams can do to deliver quality software:


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

To deliver high-quality products to customers, Agile teams and product owners have to jointly ensure the quality of the requirements and manage them effectively. Agile quality practices have to be ingrained in the team’s daily work. Ben Linders describes how it can be done.

For more than sixteen year Bits&Chips is publishing a magazine in Dutch, aimed at professionals in the Netherlands and the Flemish speaking part of Belgium. According to Nieke Roos, the English edition helps to reach the foreign knowledge workers in the region and to show the world about high tech development in the Netherlands and Belgium.

This English edition of Bits&Chips also featured the Software-Centric Systems Conference which was held on May 25 at the High Tech Campus in Eindhoven. I’m covering this conference for, see my article on Technologies and Trends in Developing Complex Software Systems.

I’m proud to be part of this first English edition, after having several Dutch articles published in Bits&Chips.

Categories: Blogs

Regional Scrum Gathering Rio, Rio de Janeiro, Brasil, June 23-25 2016

Scrum Expert - Thu, 06/09/2016 - 10:00
The Regional Scrum Gathering in Rio de Janeiro is the largest Scrum event in Latin America. In 2014, it received about 500 people and discussed topics like Scrum, Kanban, Lean, Agile and Lean Startup in lectures, workshops and open spaces. In the agenda of the Regional Scrum Gathering Rio conference, you can find topics like “Software Factory or People Factory?”, “Is Estimating a Crime?”, “Are We Really Being Agile? – Agile Patterns and Anti-Patterns”, “How coaching had helped to change my company”, “Complexity is dead: at least for the end user”, “What Type of Contract to Use in Agile Projects”. Web site: Location for the Regional Scrum Gathering Rio conference: Windsor Atlantica Hotel, Avenida Atlântica 1020, Copacabana, Rio de Janeiro, 22010-000, Brazil
Categories: Communities

In Memory of Jean Tabaka

Leading Agile - Mike Cottmeyer - Thu, 06/09/2016 - 03:41

I debated writing this post.

I considered Jean a friend.

Even though we didn’t talk often, I think she considered me a friend.

I’m sad she passed away this week.

I’d like to share a story with you guys.

When I wanted to start LeadingAgile, I was scared. I didn’t have the 100K in the bank Mitch Lacey told me I needed to start. I didn’t have space on my credit cards to fund myself for a few months. What I had were a few good relationships.

Jean was one of them.

I called Jean one day and told her what I wanted to do. She gave me good counsel. I wanted to see if I could get on Rally’s subcontractor list. I had worked for VersionOne so that was complicated. Jean went to bat for me.

Getting on Rally’s subcontractor list gave me the confidence to step out.

Even thought I never did any work for Rally, having that option in my back pocket created sufficient safety for me that I was able to be brave. Jean helped me be brave. For that I will be forever in her debt.

Who knows how things would have turned out had Jean not helped me.

I like to think I could have done it without anyone’s help.

But Jean helped.

I’ll miss Jean Tabaka forever.

Thank you Jean.

May you rest in peace.

The post In Memory of Jean Tabaka appeared first on LeadingAgile.

Categories: Blogs

Elasticsearch Throttling Indexing

Recent adventures in Zapierland had me in a somewhat scary predicament. Starting at some point last week I’d get an alert that the Elasticsearch cluster we run Graylog against had hit very high CPU, load and memory usage. I was confused… we had more than enough horsepower to handle queries and normally the cluster only uses about 10% of CPU on each node. I paused message processing (that’s a nice feature of graylog there, it just sticks the messages into a local journal) and began looking around. Nothing seemed off. Nothing stuck out in the logs. I noticed that the CPU and load eventually dropped, shrugged my shoulders and resumed message processing. Maybe a rogue query? Who knows.

A couple days later it happened again. Pause, resume. Everything began operating normally. While I had some hunches I had no solid evidence as to the cause and assumed that maybe it was time to expand the cluster. Since it wasn’t a fire (we just use graylog for internal log searching of API requests) I added a card to our trello board to just go ahead and kill two birds with one stone by upgrading Graylog and ES and ensuring we up the cluster size in the rebuilt cluster. I can handle the pause/unpause cycle in the short term.

As it continued happening daily, I got very curious. It only happened during peak load time and when there were a lot of staff members using it. And it always became 100% fine with a pause/unpause messaging cycle. I looked around some more and realized that we should tune the logging level a bit and see if anything stood out the next time it hit.

Sure enough, when our engineering team did a quick support blitz it happened again. This time the Elasticsearch logs were filled to the brim with entries like the two below.

[2016-06-06 18:20:34,880][INFO ][index.engine ] [ip-10-0-0-2.ec2.internal] [graylog2_761][0] now throttling indexing: numMergesInFlight=5, maxNumMerges=4
[2016-06-06 18:20:40,804][INFO ][index.engine ] [ip-10-0-0-2.ec2.internal] [graylog2_761][0] stop throttling indexing: numMergesInFlight=3, maxNumMerges=4

Well that’s a bit curious. Off to google. After a little searching I came across this entry in the elasticsearch reference.

Segment merging is computationally expensive, and can eat up a lot of disk I/O. Merges are scheduled to operate in the background because they can take a long time to finish, especially large segments. This is normally fine, because the rate of large segment merges is relatively rare.

But sometimes merging falls behind the ingestion rate. If this happens, Elasticsearch will automatically throttle indexing requests to a single thread. This prevents a segment explosion problem, in which hundreds of segments are generated before they can be merged. Elasticsearch will log INFO-level messages stating now throttling indexing when it detects merging falling behind indexing.

Elasticsearch defaults here are conservative: you don’t want search performance to be impacted by background merging. But sometimes (especially on SSD, or logging scenarios), the throttle limit is too low.

A key point following that statement is the revelation of what the default rate is.

The default is 20 MB/s, which is a good setting for spinning disks. If you have SSDs, you might consider increasing this to 100–200 MB/s.

Well this seems promising because we DO use SSD. From the documentation I issued a curl call to up the rate.

PUT /_cluster/settings
    "persistent" : {
        "" : "100mb"

With these settings in place I had a few hours until the next support blitz. Suffice to say it has been several days and we haven’t had to pause message processing yet. This is definitely an important setting to ensure you configure correctly when you tune the defaults on your cluster.

Categories: Blogs

A Community of Thinkers – For Jean Tabaka

AvailAgility - Karl Scotland - Wed, 06/08/2016 - 23:02

In late 2013, Jean Tabaka, Eric Willeke and Liz Keogh came up with the idea of a Community of Thinkers, with a statement about what that meant to them. Rather than post it centrally, they each posted it individually, and encouraged others to copy and paste if they agreed and supported the notion.

I never did. I don’t know why. But in light of the recent devestating news about Jean’s passing, I have decided better late than never. Jean was a wonderful person. A friend, mentor and colleague. I have many great memories of her kindness and love of life. I learnt so much from her. I am grateful that the outpouring of emotion on social media shows how many lives she touched. This seems like a great way to remember her. What if we could embody the Community of Thinkers?

“A Community of Thinkers”
I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

  • reflect and honor the practitioners who make its existence possible;
  • provide an excellent experience for its members;
  • support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
  • exemplify, as a body, the professional and humane behavior of its members;
  • engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
  • embrace newcomers to the community openly and to celebrate ongoing journeys; and,
  • thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.

Categories: Blogs

SonarQube 5.6 (LTS) in Screenshots:

Sonar - Wed, 06/08/2016 - 13:45

The wait is over! The new SonarQube Long Term Support (LTS) version is out, and it’s packed with new features to help you better manage your technical debt and operational security. It has been over a year and a half since the last Long Term Support (LTS) version was announced – a very busy year and a half. In that time, we’ve pursued three main themes:

  • Fixing the Leak
  • Adding More for Developers
  • Increasing Scalability and Security
Fixing the Leak

The Water Leak concept says you should fix new issues before bothering with old ones. After all, an issue in two-year-old code has been tested by time. Its the one you added yesterday that should be fixed immediately – while the code is still fresh in your mind.

To that end, we’ve added a number of features to keep you focused on the leak. The first is a new, fixed project home page which puts the leak front and center (okay, front and right) by highlighting the metrics on new code:

And just to make sure it doesn’t slip from view, we’ve updated the default quality gate to focus on new code as well:

Of course, it’s best of all if new problems never hit the code base. In an effort to shorten the cycle we also added the ability to analyze pull requests. Now you no longer need to wait for your code to hit the SonarQube server to see what you need to fix. Instead, you can see new issues as comments on your GitHub pull request (PR):

This is enabled as a GitHub status check, so analysis is automatic with each new push to the PR and you get a tidy summary in the check list:

Adding More for Developers

As a company of developers, and our own first users and harshest critics, we’re always focused on making the platform more usable for developers. It should come as no surprise then, that there’s a lot for developers in this version!

I’ll start with the SonarQube Quality Model, which is an easy to understand, actionable model that takes the best from SQALE and adds what was missing. It draws bugs and security vulnerabilities out of the mass of maintainability issues to clearly highlight project risk, while retaining the calculation of technical debt.

Click through on any of these issue counts, and you land at the new issues page, which is available at both global and project levels. It features an easy-to-use search, totals by either count or technical debt, and super-easy keyboard (or mouse!) navigation:

On that issues page, you may notice the next developer-centric feature: precise issue location. Now we can highlight exactly, and only the portion(s) of a line relevant to the issue:

Last but not least on the topic of Issue improvements is False Positive’s long-awaited sister: Won’t Fix:

We’ve also reworked the presentation of Metric details. The old drilldowns have been replaced by a new project Measures space, which offers a general overview:

A domain view:

A treemap, a list of files, a component tree, and of course a file listing

Increasing Scalability and Security

Even though SonarSource is a developer-centric company, we didn’t forget devops. In fact, this new LTS makes great strides in that area.

The most significant change is that analyzers no longer talk to the database. This means you don’t have to hand out your DB credentials to every Joe who wants to run an analysis. Instead, scanners talk only to the web server, and the server takes it from there.

“But wait,” you’re thinking, “you still have to pass around the user credentials to submit an analysis.”

No you don’t. We’ve added the ability to generate user tokens, so you can run an analysis without exposing your password (or user name!).

Also Worth Noting

While it shouldn’t be major news, it’s also worth noting that the new LTS drops support for Java 7. It’s Java 8+ from here on out. Among other things, the change should make your SonarQube server even faster than before!

That’s all, Folks!

Its time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

If you’ve already worked with the 5.x series, few of these things will come as a surprise. If you’re still on the previous LTS, you should fasten your seat belt. It’s gonna blow your socks off!

Categories: Open Source

Spotify Rhythm – how we get aligned (slides from my talk at Agile Sverige)

Henrik Kniberg's blog - Wed, 06/08/2016 - 12:54

Here are the slides from my talk about Spotify Rhythm at Agila Sverige.

The talk is about Spotify’s current approach to getting aligned as a company. It covers:

  • what problem we’re trying to solve, and how we’ve through two other models (OKR and Priorities & Achievements) before arriving at our current model
  • how we define “Bets” using the DIBB framework (Data-Insight-Belief-Bet)
  • how we prioritize bets using stack-ranking based on company beliefs and north star goals
  • how we visualize bets on a kanban-like company level board, and group them into Now – Next – Later columns
  • how different parts of the company visualize their own bets and align with higher level bets, using interlinked bet boards.
  • how we synchronize and prioritize our work using different cadences at different levels of the company.
  • how this model is used to support squad autonomy
  • our challenges and learnings with this so far

Holy crap how did I manage to cover all that in 10 minutes?! Guess I talked fast :)

Some sample slides below.


Stack ranked bets


Cascading Bet Boards

Squad autonomy

Categories: Blogs

Launching ASP.NET Core 1.0 course

Jimmy Bogard - Wed, 06/08/2016 - 01:02

This is a bit of a different post for me. I obviously blog and speak a lot about how I build apps at Headspring, and one question I get quite often is “can you make some courses on Pluralsight about these topics?” Years ago I co-wrote the MVC in Action books, all on my own time. I set out to do the same and create some videos, but life more or less got in the way, and I never was able to publish anything.

So rather than go through a 3rd-party learning platform, which would have to go through an approval process, I’m building out courseware for Headspring. It’s focused on how we build MVC applications, but on the new ASP.NET Core 1.0 platform. And rather than trying to do it on my own time, which means it’ll never happen, it’ll be through Headspring, which means that it will happen :)

The idea behind the course is that I’ll walk through how we build applications with ASP.NET Core 1.0, using our toolbelt of AutoMapper, MediatR, Fixie, HtmlTags and more, providing a complete end-to-end guide on both features on the new platform, and how to use them effectively.

I’ll post some more here at, just to get things started. Or if you want to go ahead and sign up for the course directly, we’ll have the full series here

Either way, I hope you enjoy!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

The Case for and Against Estimates, Part 2

Johanna Rothman - Tue, 06/07/2016 - 23:33

In the first part of this series, I said I liked order-of-magnitude estimates. I also like targets in lieu of estimates. I’ll say more about how estimates can be useful in part 3.

In this part, I’ll discuss when I don’t like estimates.

I find estimates not useful under these conditions:

  • When the people estimating are not the people doing the work.
  • When managers use old estimates for valuing the work in the project portfolio.
  • When management wants a single date instead of a date range or confidence level.

There are more possibilities for using estimates in not-so-hot ways. These are my “favorite” examples.

Let me take each of these in turn and explain how agile specifically helps these. That’s not because I think agile is the One and Only Answer. No, it’s because of the #noestimates discussion. I have used #noestimates in a staged-delivery project and on agile projects. I have not been able to do so on iterative or serial (waterfall/phase gate) projects. Of course, with my inch-pebble philosophy, I have almost always turned an iterative or serial project into some sort of incremental project.

People Estimate on Behalf of the Project Team

We each have some form of estimation bias. I have a pretty good idea of what it takes me to finish my work. When I pair with people, sometimes it takes longer as we learn how to work with each other. Sometimes, it takes much less time than we expected. I expect a superior product when I pair, and I don’t always know how long it will take us to deliver that product. (I pair-write with any number of people during the course of the year.) Even with that lack of knowledge, we can pair for a short time and project to a reasonable estimate. (Do a little work and then re-estimate.)

When people who are not part of the project team estimate on behalf of other people, they don’t know at least these things: what it will take the real project team to deliver, how the people will work together, and how/if/when the requirements will change. I have my estimation bias. You have yours. We might learn to agree if we work together. But, if we are “experts” of some sort, we don’t know what the team will encounter and how they will handle it.

I too often see experts ignore requirements risks and the potential for requirements changes. I don’t trust these kinds of software estimates.

Now, when you talk to me about construction, I might answer that we know more about construction. We have dollars per sq. foot for houses. We have dollars per road mile for roads. And, I live in Boston, the home of the Big Dig. Every time we remodeled/rebuilt our house, it came in at just 10% over the original number. We worked hard with the builder to manage that cost.

Those projects, including the Big Dig, were worth it.

How do we make software projects worth it? By delivering value as often as possible and asking these questions:

  • Is there still risk to manage?
  • Is there more value in the backlog?
  • How much more do we want to invest?

Software is not a hard product. It is infinitely malleable. What we deliver on Monday can change the estimate for what we want to deliver on Tuesday, Wednesday and Thursday. We can’t do that with hard products.

When other people estimate, we can’t use what we learn by working together and what we have learned already about this domain. Agile helps this specifically, because we deliver often and can re-estimate the backlog if we need to do so. We understand more about the remaining risks because we deliver.

Managers Use (Old) Estimates for the Project Portfolio

I have seen managers use estimates to value projects in the project portfolio. I wrote a post about that years ago: Why Cost is the Wrong Question for Evaluating Projects in Your Project Portfolio.

Here’s the problem with old estimates. Estimates expire. Estimates are good for some time period. Not forever, but for some number of weeks. Depending on how you work, maybe the estimate is good for a couple of months. Estimates expire because things change: the team might change. The codebase and the requirements have certainly changed.

However, project cost is only one part of the equation. Value has to be another part when you think about the project portfolio. Otherwise, you fall prey to the Sunk Cost Fallacy.

You might say, “We use ROI (return on investment) as a way to value projects in the project portfolio.” Now you depend on two guesses: what it will take for you to complete the project and the sales/adoption rate for the release.

ROI is a surrogate measure of value. When I have measured the actuals (what it actually took us to finish the project and the actual revenue at three, six, nine and twelve months out, we almost always did not meet the projected ROI. And, because we chose that project with great-looking ROI, we incurred a cost of delay for other projects. “If we don’t release this project because we are doing something else, what is the effect on our revenue/adoption/etc?” (See Diving for Hidden Treasures to read about the different costs of delay.)

People often say, “These two projects are equal in terms of project cost. If I don’t use ROI, how can I decide between these projects?”

I have never seen this to be true, and it’s quite difficult to predict which project will be shorter. Here are some options:

  • Use Cost of Delay as a way to value the projects in the project portfolio. See Diving for Hidden Treasures for ways to see Cost of Delay. See Manage Your Project Portfolio for many other ranking ideas for the project portfolio.
  • Determine the first releasable deliverable of value for each project. How long will that take? If you do one project, release something, does that provide you enough revenue so you can go to the other project and release something there?
  • Make all the deliverables small, so, if necessary, you could flow work from both projects through one team. The team can finish a feature/deliverable and move to the next one. I recommend using a kanban board and swarming over each feature so you get maximum throughput. Once the team has finished “enough” features, decide which project to spend more time on.

Agile helps the entire project portfolio problem because we can all see progress on an agile project: demos, product backlog burnup chart, and retrospective results. We know a lot more about what we finish and where we are headed. We can stop working on one project because we don’t leave work in an unfinished state.

Management Wants the Comfort of a Single Estimation Date

I supply a range of dates for my projects: possible, likely, pessimistic. I sometimes supply a confidence range. I have met many managers who do not want the reality of estimation. They want a single date: September 1, 2pm.

The problem is that an estimate is a guess. I can only know the exact duration or cost when I’m done with the project. I can get closer as we finish work, but I can’t know for sure months in advance. For a year-long project, I can guess as to which quarter/three month period. As we finish the project, I can spiral in on a date. By the last quarter, I can be within a couple of weeks of knowing.

Managers get paid the big bucks to manage the organization with assumptions, risks, and unknowns that we explain to them. When we work on projects, it’s our job to manage our risks and deliver value. The more value we deliver, the fewer unknowns our managers have.

Agile (and incremental approaches) help us manage those unknowns. Nothing is perfect, but they are better than other approaches.

I’ve worked with several managers who wanted one date. I gave them the pessimistic date. Sometimes, I provided the 90% confidence date. Even then, there were times we had more problems than we anticipated. Meeting that date became impossible.

A single-point estimate is something we like. Unfortunately, a single-point date is often wrong. Management wants it for any number of reasons.

If one of those reasons is assurance that the team can deliver, agile provides us numerous ways to get this result without a single-point estimate: set a target, see demos, see the product backlog burnup chart.

I have nothing against estimation when used properly. These are just three examples of improper estimate use. Estimates are guesses. In Part 3, I’ll talk when estimates might be useful.

(Sorry for the length of this post. I’ll stop writing because otherwise I’ll keep adding. Sigh.)

Categories: Blogs

Breaks Between Sprints Indicate a Problem

Learn more about transforming people, process and culture with the Real Agility Program

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Breaks Between Sprints Indicate a Problem appeared first on Agile Advice.

Categories: Blogs

SpiraPlan 5.0 Released

Scrum Expert - Tue, 06/07/2016 - 18:00
Inflectra has announced the release of SpiraTest, SpiraPlan and SpiraTeam, the latest version of its requirements management, test management and agile project-planning ALM suite. SpiraPlan is an integrated Agile solution that has the entire agile process covered. User stories, tasks, code, builds and bug-tracking are all integrated in the same tool. The new version features a completely redesigned interface that allows the whole application to be used seamlessly on all mobile and desktop devices. About Inflectra Inflectra Corporation is a privately held software company dedicated to helping its customers – large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development lifecycles, so as to decrease the time to market and increase return on investment. To learn more about Inflectra, visit
Categories: Communities

CA Technologies Delivers New Agile Management Solutions

Scrum Expert - Tue, 06/07/2016 - 17:36
CA Technologies has announced new capabilities in its Agile Management portfolio that allow organizations to deliver value faster, from upfront planning to execution to customer support. Expanded capabilities include integrations between CA Project & Portfolio Management (CA PPM) and CA Agile Central (formerly Rally). The integrated solution of CA PPM and CA Agile Central helps companies to effectively balance agility and governance by connecting the work of agile teams to the enterprise portfolio. New integrations between CA Agile Central and CA PPM allow the work development teams are undertaking in CA Agile Central to be visible to project managers in CA PPM, so resource allocations, funding, and progress of business deliverables are more transparent. Supporting an evolutionary approach to adopting agile, the integrated solution allows companies to continue using traditional methods, while growing agile adoption to deliver on portfolio investments faster—with higher quality and predictable business results. New CA Agile Central Capabilities Align Development Teams with Business Value Many agile teams face the same challenges — they have too much work in process, and not enough visibility into which work is the most important work. Allowing teams to better connect strategy to execution, CA Agile Central now offers enhanced capacity planning, team planning and release tracking. Key features include: * Enhanced capacity planning enables businesses and engineering leaders to match business priorities to available team capacity so they can balance work allocation during planning. * Team planning gives visibility into the prioritized set of features that teams will build. By [...]
Categories: Communities

Workfront Shifts to Agile

Scrum Expert - Tue, 06/07/2016 - 16:43
Workfront has announced that its new Agile capabilities allow project managers to step away from the decades-old Gantt chart as their sole visualization tool when planning projects. The new Agile view allows project managers the ability to see projects in real time, giving them even more confidence to set expectations of project teams to deliver higher quality content faster than before. In addition to taking projects out of Gantt-only view, the Workfront Agile capabilities provides an alternative to the traditional project management processes by offering an Agile methodology that can be easily adopted by enterprise teams at their own pace. The new Workfront Agile capabilities for IT and marketing teams include: * New burndown charts dynamically shift to account for quick progress updates, both at the team and project level * Interactive workboards allow users to see work move from “in planning” to “in progress” to “complete”, while displaying the number of stories and points completed as those tasks progress and ultimately reporting the productivity of the team * Dropdown navigation menus provide complete visibility and transparency at the team and project level, across multiple teams, breaking previous silos of information * Dropdown menus allow users to toggle between Agile and traditional views so teams can easily adapt and transition to Agile practices
Categories: Communities

May Highlights–Latest Articles & Videos for the SAFe of Mind

Agile Product Owner - Tue, 06/07/2016 - 16:21

Hi Folks,

This “Highlights” series captures the SAFe news and activities that haven’t been covered in other posts, but provide real value to the community. Here’s the latest roundup—a mix of new perspectives, understanding, and practical steps for successful implementation of the Framework.

New Product Manager /Product Owner (PMPO) Course and Certification
The SAFe 4.0 Product Manager / Product Owner course with PMPO Certification has been added to Scaled Agile’s role-based curriculum offering. Click here to learn more about the course. Public classes are available in multiple cities, including Boulder, Paris, Bangalore, Stockholm, Helsinki, and Bilthoven.

Reacting to a Shifting Business Environment with Modernized Processes
Medtronic, the world’s largest medical technology company, adopted SAFe. Read why in this just-published case study from Intland Software.

Too Big to Be Agile? Not With the Scaled Agile Framework’s evangelist for Agile Scrum software development, , discusses developing application systems and software products in a large enterprise with SAFe. He points out, “With SAFe, many organizations will notice they already have one-to-one mappings with many tenants of SAFe and, with some minor adjustments, fit right into the model.”

6 Biggest SAFe Agile Implementation Blunders
Senior Scrum Master, Dawn Goodman, provides six tips on what to avoid, and how to think about approaching a SAFe implementation.

SAFe Gets a New Facebook Page
Like–Comment–Share! Head over to our new SAFe Facebook page to connect and engage with Scaled Agile and the SAFe community on social media. It’s a great place to share photos, class experiences, and SAFe wins and learnings.

SAFe Program Consultants Visualized on a World Map
Our thousands of SPCs (and SPCTs) take SAFe knowledge and help enterprises drive continuous value in six continents. See what this looks like on a world map. Next stop, Antarctica?

Dean Leffingwell Videos and Podcasts
And finally, hear are some of my latest, personal thoughts on SAFe, past and future, in these recently published podcasts and videos:

Video: How to Deal With Legacy Systems, short interview with Sam Bunting of PA Consulting Group.

Podcast: What’s New With SAFe, and Why with Dave Prior. I discuss the idea of results over method debates, be it Agile, Lean, Scrum or Kanban. I also talk about the latest update to SAFe, and the new guidance to help enterprises organize around value delivery

Podcast: SAFe from the Source with Dean Leffingwell with Em-Campbell Pretty, a short story on SAFe, including how the Indiana Jones and the Temple of Doom ride factored into the journey to SAFe, the role of Scrum, differing viewpoints, the SAFe for Lean Systems Engineering branch, and much more.

We’ll keep rounding up these great resources for the community, so stay tuned to the blog.

In the meantime, stay SAFe!

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.