Mickaël’s Weblog

In his post “We’re not resources”, Mark Gregory Turansky is writing:

Talent matters.

Winning organizations build winning teams, they don’t schedule resources and they don’t break up a winning team. They pay top dollar for top talent knowing that it’s entirely talent that makes a winning team.

I had the opportunity to see this during my (short) carrier. Large team tends to force this “resource” direction (large company also obviously). Having a small team (lets say 5 to 7) of talent and senior can produce far more than a “regular” team of 30.

In the case of a large team, I prefer split into small teams (preferably using the architecture components as a guidance … yes I know, some agile folks will not agree) with leaders having a good leadership and management skills to do people management, not resource management.

Where I disagree from Mark’s point of view is the direct relation he emphasys between talent and dollars. Sure, talent people are more expensive, but dollars is not a way to get people efficient, simply a way to get them in. This article form Mary Poppendiek highlights very well this point.

Another skill that makes the difference  (in addition to talent) is sense of responsibilities (I’m back to an agile point of view ). The best talented developer will not help that much if he (or she) cares only about his code, do not try to understand code/work of the others, do not try to help level 3 support even if it’s a totally unkown area of the software for him/her.

Having teams sharing the responsibility of what they deliver, composed of talent, and leaded by a people manager (vs resource manager) is one of the best cocktail to quickly create creative softwares.

Jimmy Bogard have written a very interesting post on Flexibility and control.

He is writting: “The manager had likely fallen under the illusion of rigid control leading to more predictable success.”

His image with arrow and guided missile is terribly true and helps a lot to understand agile concept. Has I’ve already written in a post on Agile Practices With Waterfall Management, management that does not embrasse really agility (maybe due to some misunderstanding), this can produce very weird effect.

What about Program and Development Management that are using a waterfall approach with agile development team? By waterfall approach for management I’m talking about management decision not to start the development before requirements are defined, planification and release date setup. It’s not unusual to see also a stabilization phase defined as for example the last couple of iteration.

This is mainly due to:

• Product Management team is not ready at all for the first iteration,
• Infrastructure changes not identified before the first iteration,
• Product Management wants to have a full plan on the future release before starting, to prepare pre-announcement.

The final result of this approach is that the development team is not working at all…because it’s simply forbidden. The market driven approach has been well understood by Product Management and they are blocking any kind of development before they have decided what features have to be implemented.

Joaquim Rendeiro talk about co-existence of waterfall (especially for management) and agile methodology in his post on Agile or Waterfall?. Yes, they can exist but may have the consequences I’ve talked about.

IMHO, this occurs inside teams that are transitioning to agility and are not mature enough on this agile approach. As agility provide a huge responsibility and control capability to the product management, they used this extra-strength keeping in mind the waterfall approach targeting dates and content of the releases.

The development management should be the driver to accelerate the transition to a real agile approach. For example by rejecting all big kick-off meetings to start a release, and encourage a better preparation of each iteration. The development team managers should also avoid any technical discussion include an product owner and take the responsibility to make the technical choices. Often, the technical choices are delegated to product owner. Yes this is strange, but haven’t you any discussion with a product owner like: we can implement the story this way and it will cost 13 points or a different way and it will cost 21 points but this last one is less good for reasons A and B. Let guess the answer…do the shortest path. Even if this is usually the good answer from a technical perspective (I’m supporting the principle of simple design which is often shorter to implement), there is not reason to delegate this decision to product owner.

Agile approach requires a clear definition and separation of responsibility for every shareholder.

Getting agile is probably the only (or best) way for large R&D organization in a software company to setup their workforce in front of their need. They usually are working over multiple products (legacy or not), and are market driven. In small software companies, the product management marketing function is endorsed by R&D management and they work usually on a small number of projects which are at least tightly integrated, which means R&D team is focusing on only 1 common goal.

Start-up have focused/sharp vision, excellent creativity. Large company are relying on strong market analysis and capacity to move on…most of the time as soon as a startup has demonstrated new markets.  Vijay Challa talk about this in his post on Agility World 2.0.So, they have to invest (put development resources) on the products depending on the market trends, profits from each product,…etc. That’s why its important to be able to switch developers from a product to another to be reactive.

Some agile principles helps for this:

• iterations and time boxed releases to have reactivity when some resources are removed from a project,
• sharing knowledge instead of specialization to be allow reallocation,
• pair programming to reduce learning curve when new developers are working on a new project.

I tend to think that agility is maybe not always that relevant for small company, but its certainly a must have for large software company to be reactive.

Management tries to dertermine a magic number between ideal days and real days. The rational is always the same: PTO, meetings, illness…etc.

But, even if an ideal developper would exists (never ill, no PTO and no meetings) there will always be some shift between estimates and time to developpe the feature. I see at least one reason which has a significant impact IMHO: he is not working alone! He will have to synchronize with the source control before check-in. This can be done efficiently if the SCM system is efficient and longer if not…or if there is no SCM system. The result of this synchronization is absolutely unpredictable.

Maybe, the “single brain” (a team of…1) is the right approach to get accurate estimates…but it has its own drawbacks.

The best is probably experience.

Another step before check-in which may be longer than expected is the refactoring.

Product owner is a role within scrum methodology that represent the customer. The question is about a team that would like to apply Scrum methodology without such role.

The answer is definitely “No” obviously. How to use such methodology in an organization that do not provide such role. I think this can be hardly achieve by managers assuming this role but they have to be fair. The team will assume its responsibilities (sizing, self organization…etc) and the manager will validate the acheivement of the stories even if this has no value from a customer point of view. The manager then will do the buffer with the “real” customer, and takes his responsibilities.

The hard point is for the manager:

• have an iterativ approach at least (1 month is perfect) 
• create new user stories if the customer is not fully satisfied with the implementation and track them as new items,
• describe precisely the content of the user stories to help the team do a precise and accurate sizing,
• provide support to the team if they have questions on the impelmentation during the srpint,

The key point is not to have a manager which is only simple bridge between the customer and the dev team, but fully assume the role of Porduct Owner. Sure this is not easy, but this can be done this way.

This week, the team get a training on Scrum. The goal was to introduce more agility in our development methodology. After this training, managers decided to use Scrum as Agile methodology, starting in 2 weeks for our neqw internal release. That sounds good.

The team is about 18 developers and QA engineers. Scrum recommende to have about 7 folks per group. This imply to split the team into smaller groups. The current oganization is really not agile; this not so suprizing as we kept the same organization for around 11 years and we are Agile practitioners only for 3 years. So the team in splitted into 3 blocks: QA and 2 development groups (business and platform). My concern is that we keep the same organization on re-grade the existing manager as ScrumMasters. I think this is faking Scrum for 3 reasons.

First, teams are supposed to be cross-functional, which is not the case today.

The ScrumMaster is supposed to be a facilitator/moderator and contribute to the features development as the other members of the group. The existing managers do not have such contribution. More over the ScrumMaster is not supposed to have any authority, which makes very difficult the association of manager and ScrumMaster roles for one person.

And last; self-organization of the team is a fundamental of Scrum. I do not see any of that in a re-organization fully handled by managers.

I hope we will go throw a different path: let the team re-organize itself by involving every members and do not fake Scrum.

We are doing daily stand-up meetings in our team. This is one of the agile practices that has been setup (we are doing also test-first and time-boxing). These agile practices have been introduced progressively as the company decided to go on this path.

The initial goal was to improve internal communication inside the team on the project. I’m not satisfied with the result regarding our goal. Of course, every one is a little bit more aware of what’s going on in the project, but the organization of the team impact strongly the results. The team is in fact a composition of silos, and the daily stand-up is just an enumeration of information on really different areas. Finally there are very few cases where appears some shared information (I mean, information that is useful to more than only one guy).

In a certain extend, it does not provide the feeling that we are all on the same project. At least, folks have a rough view of who is doing what…which is not bad.

Today, Jeremy D. Miller have written a post that exprerss exactly my feeling:

A team building a feature is far better than a group of individuals doing tasks

Software development methodology is hot topic, especially around agility. I’m still questioning myself on the notion of “people” in these methodologies. Xtreme programming is claiming putting “people” in the core of the methodology but why there not one principal based on ”people”.  What I’ve seen in the past years is that people develop their own methodology (or used to use a specific methodology) and are not tend to change their practice. I understand this as the change is naturally rejected by humans.

Phil Haack has written an interesting post on Bug Driven Development. Beyond the post, the comment from “she” is of high interest and I agree with it. “she” says:

The thing is, “bug driven development” is the most simple and straightforward one. Its a lot associated with experience too, the more experienced one gets, the less bugs he does (but it also depends on the language, and whether it supports certain coding schemes or not)

I think that the biggest difficulty his to convince people to drastically change their way of working. This can even put endanger a project. The source of the problem is when agile methodology is enforced by management (and they usually propose scrum, read this post on this). This put useless pressure on middle management to make the team adopt the methodology, produce disruption, and finally delay in the project.

The only way to avoid any problem on this is to hire people that believe in your methodology, demonstrate results and have excellent communication skills to convince others (a kind of propaganda).

Obviously, if you have not this choice…you will have to update your methodology !! This is esactly the same as for micro-management and macro-management: some folks need micro-management even if you dislike doing it…you will have to do it.

I’m a voluntary provocative on the post title; you can read Udi’s post. Udi also refers to a prior post of him (Don’t trust developers with project management) which is of interest.

This is all about estimates done by developers. I’m hearing frequently that estimates from developers are always under estimates and should be compensate by a factor. I thinks the “underestimate” assertion is not always wrong (maybe often true…) but I disagree on the way to handle such behaviour. The management is trying to balance the initial estimation with a magic factor which should make current and future project predictable and delivered on time. This approach can be discussed for its efficiency, but I’m mainly surprised on the fact that it can be summarized this way: a manager can’t trust developer estimates, but we can trust the manager. This is to me a very strange position for a manager: how can we trust more the guy which knows the less about the “hand-on-work” when he use a magic factor? More over, why hiring a developer if you don’t trust his(her) estimates?

I think this is the role of the manager (or project lead) to improve and support his(her) team. That means to me: learn them how to be more accurate in there estimates even if finally they will use a magic factor. This can be done also by providing data and tools to allow the team to understand better their estimates errors and be more accurate in the future. The manager is also the gate keeper for all changes requested that have an impact. I do not mean reject any change, but track them to have a clear vision of the project progress.