coaching and training for adopting agile and scrum
Posted in Uncategorized

The True Difference between Agile and waterfall/traditional software development

[Context: This post is a quick copy/paste from a post in LinkedIn, but I wanted to save it. There may be some quality issues in this text, too. I hope to expand on this idea, with some images to help the understanding, in the near future.]

Most people don't seem to understand the true difference between Agile and traditional software development.

Waterfall is based on the idea that we take something we want to do, and break it down into subitems - actions or sub-components - and then deliver them separately - often by separate people who are experts in the activity or subdomain - and handing over those items to each other as needed. E.g. someone first needs to spec the requirements, then another person designs the UI, third person looks at architecture and technical design, before passing it to a fourth (UI programmer) and fifth persons (BE programmer) for coding. Then yet another person runs (often manual) tests on it and complains that it doesn't work. Yet more people might be involved in deployment, documentation, etc.

In this approach, it truly is difficult to break things down small enough.

Now, Scrum, being properly of Agile mindset, challenges this approach, by expecting people to complete items to a "potentially shippable" quality within each Sprint. "Coded but not tested" doesn't cut it, nor does "works on my machine". Each PBI is an independent capability that doesn't have to be returned to in the future, unless we specifically want to extend or modify that capability.

Enter "vertical slicing". Each slice contains all the activities needed to take an idea/need/desire from 0% to 100%. A little bit of spec, a little bit of architecture, a little bit of coding, a little bit of testing, a little bit of this and that, and at the end of the slice, that small things works in the product.

It can therefore be shown to someone, if we desire to hear feedback. Or it can be given for use if it's useful for some external purpose (not all vertical slices result in end-user valuable feature level). Or, we can simply see that we were able to make something work and we can inspect how well it works or how long it actually took us to do it.

LEARN MORE
Posted in Uncategorized

How do you keep track of your progress when working on projects?

When it comes to progress, there are only two points where we can objectively (well, with high enough confidence) know where we are - 0% and 100%. Anything in between is just guesswork. And people have made very elaborate guesswork tools and systems over the years. Big tools, great methods. But none of that has taken away the fundamental problem - it’s still just guesswork.

The problem with most guesswork is that it’s based only on what we know or can think of. The most significant risks are typically the ones that catch us by surprise. So while some amount of guessing is useful, going too far is sometimes even dangerous (but at least usually futile and waste of time). And trust me, I’ve done my share of those guessworks :). I used to love MS Project.

But, since we can only know 0% and 100%, we should focus on our attention to those numbers. 0% is easy - we haven’t done anything yet. But in waterfall, we start everything (with requirements) very early. We invest some into everything, then invest some more (planning), and invest even more (desing, then coding), before getting to the point where we can evaluate whether it all works or makes sense to our customers. So if we want to know as much of 0% as possible, we should not any work on most of the stuff.

LEARN MORE
Posted in Uncategorized

The Five Big Pitfalls in Using Scrum

The list already says more than 54 words. There's 55. But they imply much more than their measly number. Let's put a little depth into the 5 critical pitfalls.

Lacking Definition of Done

Scrum is silent on technical practices, simply because it's a work management framework and agnostic to the context. But that doesn't mean the the technical level doesn't matter. Imagine putting Kimi Räikkönen to drive a Lada, will he perform well in a race?

For a Scrum to really take off and work, the team has to at least be able to complete a working version of the product at the end of the Sprint. That's the absolute minimum. It should be better than that, really. Ideally, at the end of every single small modification. The working increment is a confirmation that whatever the team tried to do is working and enables us to actually eliminate the technical risk associated with that change. The smaller the timeframe, the smaller the risk.

LEARN MORE
Posted in Agile, Agile Success, Team Formation

Conditions for Team Formation

In the previous blogs we looked at what teams really are and what the choice of team vs. workgroup means. Here we’re getting to the very foundations of team formation as a process.

In 1936, Kurt Lewin coined his famous formula:

B = f(P, E)

LEARN MORE
Posted in Agile, Agile Success, Team Formation

Why might we choose a team approach?

In the first blog I compared two primary approaches for group coordination – workgroup and team. I also tried to emphasize that the two are both valid approaches (I’m assuming everyone understands that a bad workgroup is not a good approach). So when might we choose one or the other?

We can see the most important difference in the graphs below. On the X-axis we have time. On the Y-axis we have “value generation potential”, which is really a terrible way to say how awesome they can get. 

Pros and Cons of Workgroup

In the first graph, to the right, I have the workgroup. The great thing about a workgroup is that it’s easy to set up and get started. As long as we know who the people are and what they can do, the leader can quickly assign them to tasks and things start getting done. It’s also easy to delegate things further to other people. The main drawback is that the potential of the team is limited to the sum of the members individual abilities (including the leadership ability of the leader).

LEARN MORE
Posted in Agile, Agile Success, Team Formation

What is a real team?

The word “team” invokes very positive feelings in people. We associate it with working together towards a shared goal, as in sports. But if we look at the way these groups work in most workplaces, we often find that they really don’t match with what the literature means with a real team.

Teams and Workgroups is all about the internal stuff, not the externally visible qualities.

There are two primary ways to coordinate the collaboration inside a group of people working towards a shared product – workgroup and team. It’s a spectrum, to be precise, but we’ll look at the extremes. I’m also including a “bad workgroup” column, to emphasize that I’m trying to compare two good approaches for organizing groups, rather than “team trumps all others”.

Please keep in mind that in the table below I am talking about the same group. In all columns, we have a group with the same external purpose, the same members, and the same externally recognized leader/manager. We will also assume that the group is small, because teamwork does get difficult with group sizes exceeding 9. The only thing that differs is the way the group organizes and operates internally.

LEARN MORE
Posted in General

Comments turned off

I decided to turn off commenting on this website, because 1) there were so few comments anyways, 2) I really didn't need one more place to keep track of, and 3) there were tens of thousands of spam messages waiting for "moderation" (i.e. deletion).

This blog is more a collection of things I want to share more permanently. I will post regularly to LinkedIn and Twitter, too, so the conversation on those posts is better held there.

I hope you understand.

LEARN MORE
Posted in Uncategorized

The Project Leadership Coin

The traditional project approach has three core roles - the Customer, the Project Manager, and the Project Team. Similarly, Scrum has three roles - the Product Owner (PO), the Development Team, and the ScrumMaster.

It’s easy to see that the Customer and the Product Owner map rather nicely, since both have the money and the business need. Also the Project Team and the Development Team map nicely, since they are the people who have the skills to create the product needed by the business. 

The last one is a bit trickier. It’s easy to think that they map nicely, too. But they really map only in the goal of that role - both roles want the project to succeed. But other than that, they are the two opposite sides of the “project leadership coin”.

LEARN MORE
1 2 3 4