Project retrospection, my non-called role as acting Agile Coach

Last week I was discussing on the topic - What it takes to guide team of beginners or being agile coach in general, with Mat Hinze. That reminded me my role in previous project.

while people like Jeffrey Palermo are natural coach, personally I find it little difficult to work with beginner level people.

Looking back, here is quick highlight

• In first week, gave little presentation on what agile is and high level idea of how scrum works.
• Introduced unit test and integration test for the project. Started working in TDD way
• Change existing build process (Build = Compile) to include compile plus test execution (Which was later again changed to accommodate things like custom commonasseblyinfo, publishing coverage report and executable specification).
• Re-organized project structure to facilitate better support for loose coupling.
• Introduced boundary testing (or Scratch testing) to better integrate with external systems (and these systems where also under active development, using water-fall methodology, giving us hard time every time they give us new version).
• Introduced Dependency Injection technique to the team.
• Introduced pair programming (this was the hardest part, for me).
• Introduced using StructureMap for IoC.
• Introduced mocking technique to the team. Gave demo-cum-presentation on Rhino Mocks.
• Introduced MVP to work effectively in  ASP.NET WebForm environment. (Second hardest part on this project, for me)
• Re-factored existing code to eliminate gigantic code behind files.
• Introduced CruiseControl.net for build monitoring as well as deploying to staging environment.

Enough!!!!!!!!!!!!!!!!!!!!

What did I got out of this

• Team realized power of TDD and could see the real value behind it as oppose to doing just test first programming.
• Pairing helped team, breaking the knowledge silo and promoted collective team ownership.
• We had better success rate with sprints as we proceed further.

What was still left out:

• Project owner team, never truly realized power of Agile/Scrum
• I always had hard time convincing them for shorter sprint as oppose to 1 Month sprint.
• Sprint velocity was never established properly.
• Effectiveness of Sprint Retrospective was very low. (it turned out to be mostly time wasting activity)
• Planning meeting were always mess. Product owner were never ready with new set of requirement which they want in next sprint.
• Story related pre-requisite work was always done during planning meeting by making calls to 5 different people and then deciding on the fly, what needs to be done for the story in hand.
• All product owner never bothered to come for planning meeting.
• During sprint, one representative from product owner team was choose to answer team's question and was rarely available.
• Cubical structure made it very difficult to communicate with team effectively and has resulted in duplication of effort.
• Testing team mind-set was fully water-fall oriented. They never bothered automatic tests and continued manual testing focusing on trivial issues which were never called out in story.
• And the list can go even further, but I think I covered top pain points.

With this kind of project, I am not sure whether I succeeded in doing my best for the team. One thing however is sure enough that while I could make positive changes and affect the overall direction for technical team, I had almost no control/influence on people who were higher in the hierarchy. (By the way, I was originally hired to help them with reliable messaging which never happen in the project).

That spawns nature question, what should I have done differently to help this project better. And more importantly how would you handle this kind of situation where you don't have direct or indirect influence on people who are driving the project. ( And I am looking for answer other than; "Hey, why don't you just update your resume and start surfing dice or monster.com)

Working with high performing team

Not secret anymore, recently I have made one of the most significant move in my career my opting to work with the team HeadspringSystem, the premier agile consulting company based in Austin. It's been my pleasure to work with all BigB's like Jeffrey Palermo, Kevin Hurwitz, Mat Hinze and Jimmy Bogard.

Ever since I stated with new project with this team, I have been learning a lot every day. Be it NHibernate, NAnt, using open source project, spawning new open source project, NBehave, Community Contributed Framework, IoC or applying BDD at work; this team makes every thing so smooth and so juice that you can't live without that it.

Team operate , keeping in mind the sole intention of getting work done and giving product owner what they really like to see in the system (as oppose to doing just what they said initially).  User story flows naturally from left side of the board to Done Done Done column.

If you are wondering how this team attacks individual story, go to my buddy's blog here.

lastly, I here by taking over un-official title of least qualified team member from Matt Hinze. 

Burndown chart vs Burndown mentality

It's no surprise that scrum projects are using Burndown chart for tracking sprint progress and overall product release too.

Burndown chart, as name suggest, keeps burning task/stories as and shows what is still left out.
Every day after, stamp up meeting, is good time spot when we re-draw this chart to reflect previous day's work.

Here is the trap which I have seen many team fall in very easily. While we are using daily stand up to come up with burn DOWN chart, what we are really talking about is how much amount of task have been done (i.e. 4 hours or 1 story point etc). Now truly speaking that information is not really helpful to us. In Agile there is no look back. Whatever happened, does happened. No one in the world can go back and change them. What is important is what to do next. What I mean to say, is we need to start talking in terms of what is left in order to finish this story.

Now, does that sounds like weird argument? One might argue that, isn't that the same information. After all we know total size of the story and by telling what has been done, we can easily figure out what is left. (That's simple math I learned, way back in primary school).

Here is my answer,
My experience with past and present scrum project has taught me the above simple math of deducting completed point from original size is failing too often. While working on story we might encounter more or less complexity than originally anticipated. Which means, for then encountered simple story what is left is too less or for then encountered complex story what is left is much more. And somehow human minds are evolved in such a way that they can give more accurate answer for what is left vs how much is done.

Personally, our charts have improved a lot (in terms of reflating actual picture) when we started forcing team thinking in terms of "what is left" pattern over "what is done".

I call this pattern "BURN DOWN MENTALITY" to update burndown chart.

Thought? comments? arguments? I would love to hear.

Develop smartly :)

Xp Team sizing... Even or Odd

Yesterday, we had our sprint retrospective which brought one interesting issue.

We are team of 5 dev, 2 tester and 1 project co-ordinator.

One of the issue we have been facing since very beginning is lack of pair programming which resulted in knowledge silos getting build in the team. With extra effort and quoting past examples I succeeded in showing value in pair programming and we started doing it gradually more and more.

However last sprint's result was surprising to me. We had total 12 user stories in sprint and out of that I did 4 stories alone and then contributed for 3 more stories.

Now with the team of 5 developer, that sounds little ODD to me. So I tried to investigate this in the retrospective session. To my surprise, I heard other developers talking about working in pairs (2 pairs out of 4 developer) and their story comes out to be extra complex than what was originally thought of. So I was the ODD man out from the pair programming this time, for whole sprint.

This gives me interesting question. Should XP team always be Even size to facilitate pair programming? May be YES. (While voting for yes, I am well aware of the fact that even size might give us tie in planning session while estimating story point. My answer to this is use Feast-To-Five technique)

Anybody would like to comment? I love hearing from like minded peoples!!!!!

Develop smartly :)

How to get default value of given type

Found this interesting construct for .net based development.

While we all know default value of each type, at some point we might have generic implementation. So what if we need to make use of default value of give type?

Following method demonstrates, usage of default keyword (code sample in C#)

public T SomeMethod(this T abc)
{
if (whatever)
{
return some valid value;
}
return default(T);
}

This was new to me and in past I had situation where I wanted to return default value for variable type. Now I know exactly, how this can be done!!!!!!

Develop smartly:)

Agile Planning - Planning on wall

Till last week we were facing serious issue with respect to our sprint planning. Team is new to Agile and except me, everybody else is working on agile project for the first time.

Time was killer factor for our planning session. Almost every single time, we are running out of time and it ends up being 1.5 day planning session for 2 week sprint. (Again Business is also responsible for this mess as those user stories were half cooked meal and there wasn't any acceptance criteria)

Last week whole picture changed when we were successful in convincing business, that its important to have user story ready well before planning session. We used their own weapon against them and warned them without well defined user stories, the software is at risk and we will never be able to release it on time :)

That worked magically!

Business spent 2 days, organizing their thought, collected input from other concerned people and finally provided us well defined user stories which has clearly written acceptance criteria.

Wow... we entered greenland for the first time on the project.

Next was our turn and this time business wanted us to estimate them such that they call get idea on when can they release the product.

Looking at our history of planning this would have taken us, probably 4-5 days, if we would have continued to follow our old practice.

But we didn't had that much time. So it was necessity that became mother of new discovery, again.

Earlier when we used to estimate each story, we all where breaking it into task(This was sprint planning, against tasks and not release planning against user stories). And then discuss scope and complexity and come up with magic figure against each task. The whole operation was single threaded as everybody was on same task card and again getting conses for magic figure was taking time too.

So this time, we thought of using multi-threading for planning. And hence one of the wall of our Ping pong house, became playground for this planning. Every body in the team had 4x6 sticky note and a pen in their hand, No body seats in the room and then we have one person read story. (This guy was really proxy for business for us) Then starts Q&A session till we get all answers. Meanwhile everybody in the team uses their sticky and start writting all possible task that they can think of and stick on the wall. Sooner (less than 2 min) we have 10-12 task hanging on wall. They we just look at the cards and eliminate dubplicates. Task keeps on comming till everybody in the team, can't think of anything new.

Then starts next step, re-arrange task into logical order, either vertical or horrizontal.

Next and final step, was to give number to each of them. That starts with top most card, and any one call out number, others either agrees or give different number and then we uses Fist-to-Five to get agreement. Game is everybody vote for the number for given task, by raising either 1-5 figures. Number of figures means, different things as follow
1: Go to hell, I can't get this at all
2: I seriously doubt
3: Well may be good, I am Ok with that
4: Sounds good to me
5: totally agree

3 onwards is fine and you can accept that number for the card. However if even single 1s or 2s means call for further discussion and then second round with new figure based on that discussion.

Well, that's all. The whole thing worked dam good. Room was filled with lot of energy as against two or three sleeping members in the chair. Everybody contributed and we had our planning doen in one and half day without any overtime. We even had two 15 min break and one hour lunch break in between.

Above all, it was team's estimate. We created it together and we owned it. This has bought automatic buy-in from all members. Whole team was happy and everybody in the team had high degree of confidence in the estimation.

The whole magic worked!!!!!!!!!!!!!!!!!!!

I called it 1+1 > 2

Any thoughts, comments, queries, arguments??? I will be glad to hear.

Also how do you go for sprint planning?

Decorator pattern in Action

This time we are going to solve logging problem.
Requirement is as simple as that:
Login story: System should log all informational as well as failure messages into text file.

That sounds way simple, right? Even without using any existing logging framework.

All it takes is just one static class.
public static class Log
{
public static void Write(string message)
{
//code to write in text file
}
}

And the usage looks like
Log.Write(“something weird happen here”);

So far so good.
The solution works so far and meets our requirement.

Next, lets consider following some OOPs. Here is what I got from Head First OOA & D.
• Make sure your software does what client want it to do
• Apply OOP to make it maintainable.
• Re-factor to improve any duplication.

We have already satisfied first bullet line. So let’s proceed to second one.

One of the OOP says “Depend upon abstraction”. But in our solution, we are tightly binding client with static class. So let’s instead use interface and push all the concrete code behind it.

Our new implementation looks like this:
public interface ILogger
{
void Write(string message);
}

public class TextFileLogger : ILogger
{
private readonly ITextFileWritter _textFileWritter;

public TextFileLogger(ITextFileWritter textFileWritter)
{
_textFileWritter = textFileWritter;
}

public void Write(string message)
{
_textFileWritter.Write(message);
}
}

If we look at closely here, rather than writing code for IO into logger class, I have pushed them into their own class. Why????? Remember Single Responsibility Principle? Class should have only one reason to change, right? So our logger should be responsible for logging not for writing to text file. This also gives me good opportunity to unit test my logger. To achieve this goal, I have used one of my favorite Inversion of Control techniques called Dependency Injection [This might sounds like weird but I am favoring this approach because it gives me, unit testing benefits plus we have textFilewritter, which can be used anywhere else too].

Now, at this stage, our solution looks great. It perfectly meets client need as well as follows OOP from the maintainability point of view.

It’s been well said for software: The only constant in software is Change. So what if we have requirement coming up later: need to feed all these log messages to xyz MQ, so that somebody can take corrective action on them.

With our new code it should be that difficult as all we have to do is CHANGE TextFileLogger class. Add one line there, to make call to some class which will write into MQ.

Remember though, key here is our ability to reach at this file and CHANGE code in it. We may not be lucky to get access to source file every single time (This is the case, almost every single time when code that we wrote, is shipped as part of some framework). And again its always risky to change somebody else’s code. Now you have to test not only your new functionality but existing one too and make sure you haven’t broke any thing (Isn’t that very common, breaking existing code while making change. People working on maintenance project, knows this better than me)

Certainly, our solution is failing at this last litmus. We are in trouble again. Need Help!!!
I heard, one of our old friends, whom we never bother to call so far, can help here. So let’s knock her door. By the way, her name Decorator. Here we are at the door

Me: (Knock knock)
Someone from inside: Who is this?
Me: Hey I was looking for Decorator. Is this a right place where I can find her? I seriously need her help.
Door Opens.
Decorator: I am decorator. I am glad that you came here to help. Many programmers ignore me, either because they don’t know me or my power.
Me: What power you are talking about?
Decorator: Ability to add behavior without touching existing code.
Me: Sounds interesting. I am looking for something like that only. Could you elaborate on this.
Decorator: why not, here is what GoF says about me:
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
Me: As always, that was big bumper for me ?
Decorator: Don’t worry. Let me simplify it for you. Remember me, when you have requirement to add extra behavior on top of existing one, without changing original code.
Me: I am with you. Go ahead
Decorator: So when it comes to add behavior, all you have to do is implement existing interface, in your case, ILogger, and keep reference to original one in your new class. So the new class looks like this
public class DecoratedMSMQLogger : ILogger
{
private readonly ILogger _logger;
private readonly IMSMQWritter _msmqWritter;

public DecoratedMSMQLogger(IMSMQWritter textFileWritter, ILogger logger)
{
_msmqWritter = textFileWritter;
_logger = logger;
}

public void Write(string message)
{
_msmqWritter.Write(message);

if (_logger != null)
_logger.Write(message);
}
}
Me: Ok, and now all I am doing is passing each calls to that logger, after I am done with mine
Decorator: Exactly. And by doing this, what you just followed is called, OCP.
Me: you solved my problem. Thank you so much and I promise to visit you again and again
Decorator: my pleasure, bye bye
Me: bye

PS: sample code already uploaded in my google repository.