Agile MindStorm - Ideas, Actions, Results !!!

Decided to change name of my blog to fit what i am actually thinking and doing. New exciting posts are comming :)

When initiation a project or some other activities same questions always arise: how the team should look like? Who should be included into a team? How many team members?

It is obvious that it is a critical decision on any development project is how to organize individuals into teams and success of the project might depend on it. Although team composition depends on a lot of things let’s investigate single one - number of team members.

So, how big the team should be? Are there any obvious advantages or disadvantages?

For everyone who is familiar with any agile methodology (SCRUM, XP and others) knows that the best size of the team is from 5 to 9. I tried to think of why these numbers are suggested, but not 11 or something else. According my experience of successful (and not only) projects I noticed that in the most cases problems were caused by not effective communication - not everyone understood requirements correctly, developers improperly coordinated their work, architectural decisions were not communicated to architects, management expectations were not clearly communicated, not enough transparency communicating risks and etc. As you might notice this list can grow very long. :)

p.s. of course communication is not the only thing to blame during failure, but it for sure appears among top reasons for the most cases.

So, if we agree with the assumption described above, there must be reasons for that.

There is less communication channels
It is always more difficult communicate any information to a larger group of people and it is obvious that each new team member introduces additional N-1 (where N is team size) new so called communication channels. It becomes obvious that while team increase it becomes more difficult to share information equally among team members and someone becomes left out. And if we assume that everybody communicates with everybody we get very simple formula to count number of potential communication channels. Communication channels = N*(N-1)/2

So, as you can see number of potential communication channels increases dramatically with each additional member, so we need always keep that in mind. Of course it is ideal case when everybody communicates with everybody (that’s why word “potential” is used), but even reducing this number by half, which looks more realistic, shows same dangerous tendency.

There is less „safety“. If we keep in mind that most people are lazy, we will notice that in larger teams people tend to show less effort since they believe there are others who will pick up task or take responsibility. But smaller teams are more open for communication and there are no places to hide and everyone just have to participate in everyday life. :)

There is more possibility for constructive work in a small team to occur, since it takes more time for bigger teams to get closer and set up good relations.

There is less coordination effort in small team. Coordination of tasks and responsibilities occurs much faster and easier in a smaller team. Every team member know who is doing what in most cases for small teams.

There is less specialization and results are more visible in small teams. Small teams are more universal comparing to big teams, and team members have better knowledge of the product they are working on. It is also very difficult to fake performance in small teams and person‘s contribution are more visible and meaningfull.

Conclusion
1. Keep in mind the size of the team when starting a project
2. Consider splitting existing teams
3. Do not take advantages of large team disadvantages (either company or project) ;)

There is always a discussion during sprint planning sessions about requirements and design, what and how and etc. It seems to be that difference between WHAT and HOW is not always clear for team members and as my experience shows require exact definition within team. By the way, I assume that it might differ from team to team, due to: team experience, type of specialists within a team, level of product owner input and etc.

I noticed following problems due to different understanding of these (WHAT, HOW) terms, which of course lead to failed sprints (and we don’t want such things to happen, do we?:) ):
1. Product owner and Team have different view regarding sprint input
2. Different understanding of “scope creep” definition - f.ex. If column was forgotten in grid. Is it scope creep and should be moved to next sprint? Or is it just “forgotten” task? I understand that you might answer it depends, but the question remains and might lead to very hot discussions.

Note: These questions should arise and addressed during sprint retrospectives, but these just sometimes don’t. Please refer to post script section where sprint planning meeting is defined by the Scrum book.

In order to avoid problems discribed above I always try to detail WHAT definition in the following manner:
1. Business, market and/or users needs. These things can be measured by return of investment and other metrics that make sense in a specific case. For example, we will gain 10 customers in some country market if we are integrated with billing system X. In other words I call this part WHY, which helps team members to understand the actual value we are planning to introduce.
2. Some initial analysis by product owner (or his analytics team) helps to introduce product requirements (or software solution) - actual explanation of WHAT needs to be done within the solution/system/product scope. This section explains the actual goal for the team, the results to be presented at sprint review - it can include mandatory data to be displayed, minimal actions to be performed.

Regarding HOW definition, I expect following from the team:
1. After business goals and actual results are understood, team is ready to start working on high level DESIGN of the implementation.
2. In parallel or after making the design team can move to TASKs identification.

In my opinion all details like which columns should be displayed and which not, how the buttons will appear and etc should be in team’s responsibility and should be included in HOW definition. I intend to call these kinds of “requirements” implementation details rather than product/project requirements.

I have only one strict rule - implementation details can be managed easily by the team (added, changed, removed) unless these actions don’t break WHAT definition of the specific requirements. In other words implementation details should be the first in the line for tradeoffs and should never be treated as scope creep in case if main goal can be successfully achieved.

Summarizing everything above - clarified definition of WHAT and HOW terms help product owner prepare better input into sprint due following reasons:
1. Level of business, feature requirements detalization is defined within team.
2. Better understanding what scope creep is and what “forgotten” task is.
3. Better sprint goal definition and understanding, which automatically leads to better spring reviews (or results acceptance)

P.S. inspired by this post and problems in daily work :)

P.S.S. Sprint Planning by the Book
There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?” part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of “What?” Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint.
Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that will be met through the implementation of the Product Backlog. This is a statement that provides guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release goal.
The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.

In the second part of the Sprint Planning Meeting, the Team addresses the question of “How?” During the second four hours of the Sprint Planning Meeting, the Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) into a done increment. The Team usually starts by designing the work. While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day. This task list is called the Sprint Backlog. The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint.

I am working as project manager for a while and as the result i have to deal with different conflicts which periodically appear among team members. Even though my teams are built up only from real proffesionals which know what they are doing, but conflicts seems to be inevitable since people spend quite a lot of time together. And reasons are sometimes so different ... Those vary from bad oddor to arguing which implementation approach is the best.

As i am result oriented - one of my goals is have highly efficient and productive team. And it is not only that we are officially working in agile environment now (i was never fond of beurocracy and conforming stupid rules) and one of the scrum goals is to have highly performing team. Since i am pretty sure that only success makes people happy and only this allows to enjoy the job. Since i saw a lot of examples (and not only in Agile teams) where even technically easy and not interesting thing can make team happy since it brings a lot of value and done on time!

It is also important to highlight that some conflicts may be usefull while they can lead into some good/constructive decisions. Two team members and an architect may argue about 2 development approaches for two days and finally notice that completly different approach is the best. But in this case as scrum master (project manager) you must track this issue very carefully, since such discussion might lead into complete failure (none of the approaches is chosen and sprint/project/... is late).

But how to solve conflicts anyway?

In case if agile environment is taken into account most of the problems/complaints will be addressed to Scrum Master, since he must handle all the impediments which occur in a team‘s way. (Well, in other environmetns there will be a different person - project manager, team leader and etc.) As i noticed from my experience it is better that someone who complaints about something/someone would directly sovle the problem with the person who is the root of the problem, and avoid becoming an advocate of both sides. In this way impact is understood better by both sides and everyone can take corrective actions to avoid similar issues in future. It is like helping people to learn on their mistakes. So, it seems to be that the main goal of conflict solving is to lead/coach people and make them to solve their problem by themselves. It could be done in several steps, for example:

1. Ask person if he tried to share problem with the person X ? If not, than the guy should be suggested to do so.
2. If #1 is not working. Then you can suggest going with him to person X and support. It can be additional motivation or just root of the problem might be someone from other department.
3. If #2 is not working. Then you must share the problem with the person alone, but it should be done anonymously. You should tell the person who complaints about that you will inform person X about him, since anonymous complants are not acceptable.
   

But in any way you need notice when you are being manipulated and stop this as soon as notice it - use your authority in this case ;)

You can find a lot of free and not only tools for so called product management but at least i constantly face some problems using them:

- have too much features and very complicated

- difficult to integrate with already used software within the company

- software doesn't totally address problems that you really need to solve


So i decided to try out excel to solve my problems.

I am leading integration projects in the company i am working in, as the result i have several so called product lines (for different business needs) with it's sub-projects and own release versions.


The main problem i experience is to manage communication flows while elaborating concept of a specific feature for a specific product line and have clear understanding if features can be passed to development or not. Excel file is available here. (let me know if the link is broken and i will update it)


So, my goal is avoid missing main decisions points before moving features into development
1. Confirm concept
2. Confirm feasibility study results
3. Put (or not) on the shelve for development


Usage of this excel file is simple as 123. I open it every morning and plan my daily activities based on already achieved results and current priorities - communication with analysts, account managers, customers and etc.

Don't write developer stories, write user stories :) Always look from user perspective.
Very interesting interview with Jeff Patton.

Treat user story as "token for a conversation" !

p.s. also you can find very interesting slides for deeper digging into the problem - link.

Many advertisers always need to make a decision - should they use display advertising or search engine advertising. Both have it's advantages and disadvantages.

Display advertising is still used to achieve brand awareness and attract customers to buy things, but these do not always deliver the best return on investment. In order to improve it advertisers try to target display ads, based on geographical location, time scheduling and etc.

But, there is a common believe that Search engine advertising delivers a better return on investment since it is cheaper and targeting seems to be better here. (IMHO: social ads outstands these both on this aspect)

But it is obvious that combination of both advertising approachs can bring you best results:
1. Combining statistics from search campaigns with the statistics from display campaigns will allow to split advertisment budget more effectivelly
2. With the help of tracking campaigns you can easily measure effectiveness of campaigns (f.ex. make better decision for "last click" measurement; path to lead)
3. increase visitor traffic to your website more effectivelly (with the help of better targeting)

Also we shouldn' forget about social medias (Facebook, Twitter and others)... By the way - check out this ad server :)

I've recently watched one of the greatest TED's videos called The Paradox of Choice.

It defently becomes very difficult to make a decision and it is not only related to buying things, but also software development and other aspects of life.

Let's for example take software development:
1. Management - Classic approach, Agile(SCRUM, XP), RUP and other iterative (and not only) methodologies
2. Coding - tons of patterns and approaches, a lot of universal programming languages

As it was mentioned in the video - knowledge can not be complete and holistic. So we need to make assumptions, trust someone (average like/don like as it is done in Amazon or other resources) or apply other criterias to make decision making easier.

To make myself clear let's imagine two situations:
1. You want to buy a car and you come to a place with 100 cars. All cars are in a similar price range. The only thing you have is some technical information for each car.
2. In other situation everything is the same as in one above, BUT! Before comming to that place you had a chance to discuss your potential purchace with similar car users on Facebook (they would share their own experience of usage and etc.), gather different information from possibble "experts" (well, you can't be 100% sure :)) and so on...

At least for me it is obvious that for average person in the world it is easier to make a decision based on average (or the most common) opinion. That's why tagging, groups in social networks, products linking (people who like this like that), websites that compare different products are so popular.

What else can be invented to help people make their choice?...

Scrum is just another one of those trendy buzzwords - XP, Agile and etc. It becomes obvious that it doesn't offer any revolutionary or practical approaches to software development. For example my father replied - "So what!? we had daily stand ups everyday and periodical results reviews...", when i told him about the new adopted process.

However it can be easily abused by and appeals to micromanagers and people who generally lack any technical or management skills. It just creates an impression that project is moving along and tasks are getting done "on time", but the end result is usually a buggy product held together by duct tape.

Neither process or methodology will deliver good results if team is not motivated or interested in project. And good team will always find good solutions.

Here you go, very interesting article.