Why sprint success is important
 

In Agile environment, some of the committed stories may not be completed at the end of the iteration. For example, in Scrum, the stories roll to the next sprint. There could be various reasons why some of the stories could not be achieved. Reasons include (not limited to) blockers, inefficiency, improper sync between team members, missing clarity, support from other teams, priority etc. A casual look on this can make someone think this is normal. But sprint success has a huge impact on the long term success of the team and the product.

Fig: Success

Following are the some of the reasons why sprint success is important.

  • Morale : The team members self esteem actually gets higher when they achieve their goal. This breads confidence and help them to get better a their game, which can lead to more success.

  • Habit: Success breads happiness and more success. At the same time, failure breads failure. Also success/failure on one aspect of life can cause ripple effect on the rest of the life. We should be focused on success on every aspect of life so that it can bread in to itself.

Fig: Habit Loop

  • Fine reputation: More than any thing else, team will be very proud when they are able to successfully achieve the sprint goals consistently. Their reputation and respect around the company can actually go up and they will have to live up to that standard.

  • High standards: Team starts to set higher standard for themselves when they have high reputation. This helps them to get better at questioning, coding, testing, deploying and showcasing etc and improves their living standards in a holistic way.

  • Team bonding: When the team have a standard to live up to, they come together and get the things done, keeping aside the petty things. The goal becomes  bigger than individuals and  deliver thing as a team. This leads to higher team bonding and it reinforces their standards, reputation, habit and morale.

These are some of the main reasons why sprint success is important. When we focus on success, more positive things happen to the team and to the product that they work on.

Does size matter?
 

Estimations in scrum/agile environments often gets tangled in conversations about how big of an effort that is required. The questions that are often asked are “how much of effort?”, “how long/sprints it will take?”, “Is it too complex?”

Scrum provides a model where these questions are easily compressed to a simple thing called story points. Story points is a number denoting the complexity/effort/time taken by the team to solve a problem (story). Story points are often a number of Fibonacci series. (1, 2, 3, 5, 8, 13 …). The scrum team defines what it means by a 1 pointer story. For example one of our teams defined a 1 pointer as “one line of code change”.  Also as the number of unknowns in a story is high, team provide higher story points for the story.

However the size of the story points is not important because

  • Story point size is specific to the team and can not be used to compare teams. A story could be sized differently by different teams based on the understanding of the product, technology and experience.
  • When a management provides a commitment on a given epic/release to the customer, the delivery timeline is often determined by the velocity and not by individual story sizes.
  • Story points are a relative sizing of the stories and not a exact reflection of complexity/effort
  • Bigger story points does not mean higher customer value. A refactoring story or a story of lower business impact could be sized bigger.
  • Story points are time bound. The team could size the story differently depending on their understanding, as their knowledge/understanding changes their story sizes also change. This is one of the reasons some teams re-look at the story sizes during sprint planning although they are sized.

Please let us know your thoughts, using story points? does size matter?

Agile architect
 

In a typical agile environment, as there is no specific design phase, and there are often questions about when the design and architecture happens. There is continuous evolution of architecture and design that happens during the sprint and iterations. Also the conventional roles like Managers and Architects have no room in an agile environment. In this article we will discuss who do we call an Architect in an agile environment and what are their characteristics.

Agile Architect

An agile architect is a developer working and taking the most important technical decisions on the product. This is generally a person who has deep knowledge of the product and the technologies used and have great ownership in taking it to the next level. This definition beats the conventional definitions of a software architect who generally creates artifacts (like class diagram, sequence diagram etc) to be consumed by developers. An agile architect also do these conventional things in order to empower other developers, but also leads & helps the team to solve daily problems faced to implement the technical direction.

Characteristics

  • Be Agile: Agile architects are highly flexible and adaptable to changing requirements and environments and always open to changes.
  • Right tool for the problem : Agile architects often have good knowledge on more than one development language and are always open to newer technologies and solutions. When they are solving an intense problem, they use the right tool to solve that.
  • Emergent Design: Agile architects know that we can not fix the architecture at one go while the requirements keeps changing. So they are always ready to change the architecture and design based on the current business requirements.
  • Always Learning: They know there is always a better way to do thing and are open to do changes to their current tools, techniques and processes.
  • Refactor it in free time: When code does not reach perfection, they are open to achieve the business results and then do code refactoring to fix the flaws.
  • TDD/BDD: Agile architects always follow best practices like TDD/BDD so that the code is always nimble to new architectural changes.
  • Team along: As architecture and design is in the hands of every developer, agile architects always bring the team along and continuously get their inputs and provide technical directions.
  • Respect: There is no ivory tower for an agile architect, they are always part of the team and delivering results. So they respect other team members opinions and ideas and focus on delivering the best results for the product.

In this ever changing business environment, developers are often asked to deliver more and more in less time. Agile architects are a big asset to a team in providing technical, architectural and design guidance to the team.

Self Organizing teams
 

We all hear that Agile teams need to be self-organized. However there is not enough talked about what it means by self-organized. In this article, we will discuss the various qualities of self-organized teams.

  • High levels of personal responsibility

Self-organized team members are highly responsible individuals. They value the importance of their contribution to the overall success of the project. Because of this they do things on time, be available, and develop great relationship with other team members. When things are not happening as required, they take responsibility and do their part to get things done.

  • Put team first Team work
Team work

Being organized also mean being able to see the bigger picture. Self-organized team members always put team before them. Individuals have great respect for a combined democratic team decision than an ego-centric decision.

  • Openly ask and provide help Help me
Help me

Everyone is a learner and beginner before being an expert. So self-organized team help other team members for their short comings and also openly ask for help. They coach their fellow members and give them time to improve. As there are no shaming/blaming any one can ask for help without fear of being criticized.

  • Hold each other accountable
Pointing the finger

Pointing the finger

Self-organized teams are mostly a closed group and they have high levels of emotional security with each other. So they “call spade a spade” openly and bring up crucial topics and iron them out sooner. This not only happens at the same org level but they have no fear to hold a superior accountable.

  • High standards Its a Promise
Its a Promise

They agree upon nothing less than the best. Team members agree on a common set of standards which they continuously improve. They seek advice from industry veterans, architects, managers and anyone who can help improve themselves and the team.

  • NO managers required

They understand the strength and weakness of not only themselves but also other fellow team members. By respectfully and openly talking and holding each other accountable, team gets better at their game. Also self-organizing teams pick and choose who gets into their team. They often interview new individuals and sets very high expectations from the day one. Instead of managers, self-organized teams rather require a coach who will guide them from outside.

  • Highly mature

Maturity not only comes with age, but also with the company of highly mature individuals. Self-reinforcement of high standards and accountability makes them mature and the team members self-esteem is often very high.

  • Enjoy the company

Last but not the least, self-organized team enjoy their time together. They combine specific business meetings at various places where they enjoy the time and at the same time business gets done. They make fun, laugh, and merry together so that life becomes less stressful.

After years in Agility
 

It’s been few years since I started following agile methodology. When I look back it’s interesting and happy journey. Was thinking about the book (User stories applied) which introduced me to Agile world. Back then, I read the book like a story book. Now I re-read the book after two years after practicing Agile. It was a fantastic read! I thought of sharing few fundamental things for being in an agile team.

  1. Team > Individual : When you are part of an Agile team, the focus shifts from individuals to the team . This will be a big change for those who come from waterfall model. Although during the standup meetings people talk about their achievements for the day and the next actions, it’s not the individuals work alone that make sprints successful. Things like, taking up pending tasks, helping team members complete tasks, pair-programming, looking for the overall success of the business etc. are thing which make significant impact than an individual’s ability to write optimal code/test.
  2. Where is the Design : When I came from the waterfall model, I was surprised that there is no definite design phase. But soon I realize that design is happening in iteration over a period of time. While being in a sprint, Design happens when we do sprint planning and tasking, design happens when we do the pair programming, it happens when we do TDD. This way, there is more scope for the developers to think about code and design, than a single monolithic time slot to think through design.
  3. Agility is different from being in an agile team : Having an agile mindset is completely different from being part of an Agile team. Being part of Agile team gives us leverage to do iterative development, do the ceremonies of agile process etc. But when we have not imbibed the principles and the manifesto behind Agile, it’s not Agility.
  4. Communication : Focus and Communication are fundamental to any successful sprint team. When there is no direct communication, thoughts & opinions are not converted to actions. Be it daily standup meetings or technical discussions/pair-programming/or during sprint planning, connected and collaborative people can only create beautiful software.
  5. Practice, practice, practice : There is no testing phase, there is no business verification phase, nor there is any formal review process. How can we sustain quality ? how can we insure reliability ? The answer to these questions come from the software development practices like TDD, BDD, emergent design, CI etc. Agile provides a way to use these practices. Apart from the acceptance criteria for a story, Definition of Done(DOD) governs the acceptance criteria for all stories. When we have DOD covering these practices, it becomes a standard for ensuring quality. There techniques and practices in combination with Agile process can help to deliver continuous business value while ensuring good quality.

There are an indefinite list of advantages for doing iterative development over waterfall and vice-versa. Although Agile, helps to deliver software faster to clients, there can be projects where regular waterfall model might help. We need to be choosy in selecting our process for each and every project that we work on. Provide your inputs and thoughts on this topic in comments.

Choosing between Trunk based development(TBD) vs Feature branching
 

In a development environment like scrum, XP the branching strategy can significantly impact the overall speed of delivery of the product. There has been detailed documentation on the various branching strategies, and you can encounter TBD (Trunk based development), feature branching. In this article,  am covering the various factors that can impact the success or failure of a these branching strategy.

What is feature branching:

In this method, there is a code branch created for each and every feature. In agile based environments, typically, a branch is created for every story in the sprint.

 

What is Trunk based Development (TBD): When a single trunk/branch is used to create all the features of the product, then its called Trunk based development. Often a release branch is created when ever there is a release that is pushed to production.

Following are the various factors to look at before selecting Trunk based vs feature branching.

  • location of team members: when team members are co-located, the trunk is the best bet, helps us to get faster feedback. Also team can just talk about the code changes directly. Since the feedback will be faster in a single trunk, the team need to sync up more frequently. Co-location enables this sync trunk changes to happen frequently and faster. When there is a distributed environment (often in our teams), feature branching works best.

  • speed development environment: In a high speed dev environment, the trunk just shines as there are less and less process overhead, like branching, Pull request, review etc. Feature branching shines well when there is less speed in churning code.

  • size of code base: Insanely higher number of code lines can be better handled using feature branching. But for smaller code base, the cost of creating branches etc can be higher.

In our team meetings, we often talk about the right tools for the problem at hand. And using the right branching strategy is an important decision. We often question ourselves if the strategy is right for the given epic/sprint. If the answer is NO for few sprints, we know, we need to change something!

Please comment and let us know your opinion.

Projects do FAIL. It’s NOT only Code
 

It is NOT only code

We recently failed in our product. The 6 persons effort for nearly 2 years went into nothing. Besides we had all kind of testing, functional, unit, integrations, load test, stress test etc, to protect the application from any kind of questioning. When the management and product team took a decision about scraping the product, the scrum team was awestruck.  Soon all water cooler conversations were only about this. Team retrospected a lot about what has just happened and discussed everything under the sun that could have been better. Below are few pointers from that.

crash

Projects and products do fail

Software industry exists and continues to get better just because someone is continuing to write good/better code and solving problems. If we see the history of this industry, we just had assembly language, then we created abstractions after abstractions and OOPS, functional etc. As we progressed and got better, our ability to focus on the primary objective seems to be lost ie Problem solving. So when software “just don’t work, get scrapped“. This is what most developers conclude when project get scraped.

Stakeholders need to be happy

A projects need support and buy-in from all part of the organization. This includes marketing, management, product org, and of-course the customers. Each of them have a role to play in-order to successfully deliver the product the to customer. When one of them does not align to the vision and mission of the Product, it will ultimately fail.

stakeholders

When People change, alignment also changes.

Lot many times, when senior management changes, the whole mission of the company or division also changes drastically. This might be because they bring a new perspective, ideas and ways of doing things.

change

Competing products

Product acquisition and market reaction to a new products can cause products to be abandoned. Its often survival of the fittest. As a developer, Competition is healthy when it does not affect my product drastically. But unfortunately, businesses can not function like that. Ultimately, the product which the customer wants the most wins.

competition

Great products may not sell

Developers often think we need to build a great product in-order to capture the market and excite the customer. Great products also need great sales people to sell them.

sell

Timing

Its all about timing!. One of my friend told me an example of touch-based Windows mobile which was available very long before iPhones and Android dominated the mobile industry. Even though the product was good, there were lots of timing issues the market was not ready, Touch was not affordable etc.

timing

SO on and On

There are various reasons because of which leads to a failed software project. I have listed some of them here, But the list is infinite. And of-course Code is one of them.

Maintaining IEnumerable-Yield Data Pipeline is Hard
 

C# and .Net had IEnumerable and yield since its early versions. And I think its one of the most misunderstood features of C#. This is because of the pattern of deferred/lazy execution implementation.  Before we delve deep into this let us understand the iterator model.

IEnumerable and IEnumerator:

This is the foundation of the C# Iterator pattern and there are a number of detailed articles about this by Eric Lippert. The simple example is here.

There is a basket full of Oranges.

 
public class Basket
{
    private readonly IEnumerable Oranges;

    public Basket(IEnumerable oranges)
    {
        Oranges = oranges;
    }

    public IEnumerable GetOranges()
    {
        return Oranges;
    }
}

public class Orange
{
    public int NumberOfSlices { get; set; }

    public void Peal()
    {
            
    }

    public void Consume()
    {
            
    }
}

And if we have to consume oranges, we will have to peel each one of them. So we can use a simple iterator pattern on them.

var basket = new Basket(new [] { new Orange(), new Orange(), new Orange() });
foreach (var orange in basket.GetOranges())
{
    orange.Peal();
    orange.Consume();
}

But the problem is, we need not consume all the oranges from the basket at one go (I am not Hungry ;-).
So how can I get one orange from the basket at a time? or whenever I am Hungry?

Yield:

C# Yield keyword provides an answer to this problem. Slightly changing the Basket class using Yield keyword. (signature of the GetOranges Method not changed)

public class Basket
{
    private readonly Orange[] _oranges;

    public Basket(Orange[] oranges)
    {
        _oranges = oranges;
    }

    public IEnumerable GetOranges()
    {
        for (int i = 0; i < _oranges.Length; i++)
        {
            yield return _oranges[i];
        }
    }
}

Now the basket will provide one Orange at a time. ie when MoveNext() Method of the IEnumerator is called. In other words, we have paused execution of the “for” loop in GetOranges method till the time the next Orange is required.

Or in more technical words, until you Enumerate, the data will not be fetched and once Enumerated, there is no data. It all boils down to “when you Enumerate”.

The Maintenance Problem:

This is tricky for developers who are inheriting an existing code base. A developer might accidentally add an Enumeration before the place where it actually has to. The next time or When the original Enumeration happens, it can not find any new data and the iterator just completes without any looping. This can happen very silently without any exceptions. So care to be taken to see where we are yielding and where we are Enumerating.

“Yield return” is a great feature in C#, but use it with caution.  Let me know your thoughts.