Category: team

Half-dead project saved! Thank you - Direct Communication

May 21, 2009 by Przemysław Bielicki

Picture (c) Przemyslaw Bielicki

In my previous post I shortly described the half-dead project in an over-waterfall company me and my team had to save three months before production. In this part I will show you how direct (instead of discrete) communication with customer or good Product Owner in general can help saving almost dead projects.

As I described earlier me and my team had a lot of problems with the systems we had to integrate - technical issues were present but they were not dominant, even taking into account the fact that the team was not experienced in .NET and T-SQL stuff.

Project teams are not teams

May 12, 2009 by Mendelt Siebenga

I want you to do a little experiment. First search for the word 'team' on this site. By the time I wrote this article I got 325 results but that might be more now. Now click on the team tag right between 'TDD' and 'template' in the tag-list, only 26 articles are actually about teams.

What are teams?
Many books and articles are written about team-roles, team-size, team-self-organization or team-cross-functionality to name a few. One of the prerequisites is always stable teams, for many of the agile thought leaders the existence of teams is self evident, it's hardly ever talked about. Unfortunately many organizations do not really have teams. They assign people to projects instead.

Direct communication as a half-dead project saver: When you start in an over-waterfall company

April 30, 2009 by Przemysław Bielicki

Picture courtesy of clagnut@flickr

At the end of year 2008 our team was given a project that was critical from the $$ point of view. We had to deliver the project by the end of March 2009 in order to avoid huge fees from our customer. The problem was that the project we got was being developed by different team in different location and the quality of the existing solution was at least questionable. It turned out that the whole old team left the company and our small commando squad had to save the day. I just have to mention that the company we all worked for was a pure-waterfall monster.

You know, agile books are fun to read, but how do you start it if you happen to be a developer in a pure waterfall company on an impossible project? I went through it and going to show what worked well for us. I will tell how we were able to get an impossible project apply the agile principles and survive.

The value of Big Design up Front

April 28, 2009 by Mendelt Siebenga

Lets start my first article on AgileSoftwareDevelopment.com with a controversial title. Just to get your attention. You're still reading? See! It works!

I often see teams, even teams that claim to be doing agile spend several weeks or even months at the start of a project doing requirements, analysis, design and planning. BDUF is a habit many people find hard to give up. Team members instinctively feel there's something of value in that first stage of a project they'll lose when they just dive in and start creating software. That value is not in the documentation they deliver, but it's something they do during those activities that they forget to do later on. Lets look at a typical project to see what people do during that first phase that makes it valuable.

Livestock

March 17, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

"How many resources do you need for this project?”. "How much headcount” - or even: "how many headcounts” – "do we need to hire?” If you are working or have been working in any sort of corporate environment, chances are that you have heared sentences like that. If you are a project manager, you are maybe even using them in your daily work. This sort of vocabulary became common in the software industry and people use it without giving any thought to what these words really represent. "Human Resources” is typically the name of your people-management departament.

If you use phrases like that, please stop. Now. Not because it is offensive to the ones you call "resources” (though it is), not because you are vulgarizing the english language (you probably are, but I am not a native English speaker, so I don't much care. But similarly ugly HR-type phrases made it to my mother tongue unfortunately).

The valid, business-related reason for stopping this sort of language is that reffering to your people as "resources” skews reality and does measurable harm to your projects.

Skip the Daily Scrum? No, thank you!

March 11, 2009 by Peter Stevens

Last week I gave an introductory talk about Scrum to a group of people in Zürich. One participant asked if it would be OK to make the Daily Scrum a Weekly Scrum? My answer: No way!

The Daily Scrum exists to enable self organization. It helps the team focus, communicate and identify impediments. The team members communicate to each other their progress, goals and impediments. The team members identify how they can help each other to reach the shared goal of the sprint.

Each team member answers three questions:

1. What did you accomplish yesterday?
2. What is your goal for today?
3. What is preventing you from accomplishing your goals?

Low Tech Rituals

March 3, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

"Still working the old fashioned way with whiteboards, spreadsheets and outdated software?” – I have stumbled upon an agile consulting company's web site with this slogan on the main page the other day. Efficiency! Speed! High Tech! Aren't we all supposed to be after these? Well – not at all times. So yes – our team maintains the old fashioned habits, uses low-tech, old school corkboards, does the planning sessions playing planning poker with actual playing cards (Piatnik brand if am not mistaken). We even sometimes plot the burndown charts manually, with pen and pencil. And we do it for a reason.

Don't get me wrong – the modern, efficient tools are useful. Hell, my company is making money producing and selling them! But – they are not everything, and they are not always appropriate. Use them as a tool, not as a gospel. There are things more important for your team's and project's success than the use of fancy software.

The quality of the team and the caliber of its members is more important than the efficiency of its processes – nothing controversial about this statement really, this fact has been well documented in some pretty classic books on team management ("Good To Great” by Jim Collins comes to mind). And the old fashioned rituals are crucial in maintaining the team spirit and identity. This is because people happen to be wired in such a way that it makes them feel safe and comfortable if they can devote some time every day to repeatable old habits. And teams become better integrated if they have some common habits that they care to repeat every day – as a team. Liturgies and rituals do matter a lot – and there is no reason for these rituals to be overly efficient. That's not their purpose to be efficient.

Product-Owner: Are you a chicken?

March 2, 2009 by Peter Stevens

Picture courtesy of Kevin Hutchinson@Flickr

One key to success in any development project is the collaboration between the customer and the team. As Product Owner, you are either the customer or the conduit to the customer. Your job is to guide the development effort to a successful conclusion. No one on the team is pulled in more directions at once than you are. You want your team to work effectively. You want your team to build the right product.

You must allocate the right amount of your time between team, customers, management and other duties. Are you spending enough time with the team? How much time is enough? Does the team even want you to be present at their meetings? If not, why not? And what are the implications of not spending enough time with your team? Three suggestions for better collaboration with the team.

Real Agile Teams Can Flock

December 9, 2008 by JurgenAppelo

People often try to solve problems by introducing rules in an organization, in the form of "When situation X occurs again, you must do Y." I admit that I am sometimes guilty of such behavior myself, though I am convinced that it is not the best approach. It is better to leave rule selection to individual team members, and instead focus on imposing the proper constraints. Agile software development should be about setting constraints, not rules.

It has been discovered that the flocking of birds can easily be modeled on a computer. This behavior, which is also apparent in many other kinds of animals, emerges through the application of a few very simple constraints:

1. Don't leave the group;
2. Don't bump into each other;
3. Fly in the same direction.

Specific implementations of these constraints are often used in the movie industry to create computer animated birds, bats, fish, penguins, you name it. (An example of such a model of flocking behavior is available here.)

But They Like It When I Tell Them What To Do!

December 5, 2008 by mcottmeyer

Okay… I am unexpectedly out on a client site this week and I have not had time to think, let alone write, let alone write anything interesting or worth reading. So, in lieu of a writing a meaty blog post, I am going to tell you guys a little story.

Earlier today I was talking with a traditional project manager trying to get her head around what it will mean to make the switch to agile. Keep in mind, I have been on this client's site the past two days. We have been breaking down traditional notions of requirements, engineering practices, quality assurance, organizational structure, and team structure. We have discussed self-organization, empowerment, and individual accountability.

As we were wrapping up this afternoon I could see that this lady was struggling. This transition was really going to impact her job and force her to reevaluate her management style and approach to project leadership. We talked briefly again about the idea of empowerment and self-organization and how she was going to have to learn to let go.

She turned to me and said… but Mike… they like it when I tell them what to do.