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.

Sad Mad and Glad Retrospective
 


One of the powerful retrospective getting very popular lately is Sad/Mad and Glad. Many organizations don’t even conduct it as they are afraid to talk about employee challenges. There are obviously pros and cons but making it work truly helps you to achieve more.

Prerequisites :-

  • Your team and your presence
  • Sticky notes (Three colors)
  • Enough Pens
  • Open minded motivated teams

In this retrospective, you ask your team to get into a room.  Every colored sticky note represent Sad/Mad or Glad respectively.  Probably pasting a diagram like below in room would provide a better clarity for your team in terms of what does it mean.

Further you can ask every individual to write up the areas what they are happy about it (Glad), don’t like it (Sad) or frustrated with it (Mad). I always recommend individual team members to write their names against each sticky note else it would just become a political battle. I have seen instances where people just write some crap either because they did not have good appraisal last time or not able to be in pace with others. If you find an item which has something written in mad and individual does not want to even talk about it, it means either its fake or written with wrong intention. There are some people very shy and not willing to open at all. They should go to their manager or who is driving sad mad/glad to discuss the area of concern.

Once everyone is done with writing, spend an hour or so reading every item and discuss that with team. Remember the goal is to share as much as information about the issue and gaining more details around the problem while not fixing the problem there itself. This would be good input to take it forward as employee happiness and moral is very critical to agile success.

Things to remember while doing Sad/Mad & Glad :-

  • Must discuss or make every item visible to every individual unless there is a derogatory remarks which is not acceptable.
  • Team to think of success of team and project rather considering this as revenge material.
  • Everyone must open up. If you don’t have guts to talk about your challenge then don’t even write it. You are just creating a FUSS which is either not true or you don’t know what is this the right forum to talk about it.
  • Refrain from making comments about individual if you don’t have supporting material. The world is not perfect and even the goal is to identify the improve system over making it worse
  • BE MATURE
  • Should not be anonymous.
  • Don’t abuse it. It is conducted to the best interest of an individual and it should never be use as tool to fulfill your political battle.
  • Not every problem can be fixed eventually. Somebody writes that I don’t feel like working doesn’t mean you would allow him to sleep in the office.
  • Don’t fix the problems during this retrospective.

The benefits I see with this retrospective are :-

  • Gives lots of motivation to team when go over “Glad” items.
  • Give an opportunity to an employee to express their challenges.
  • Bring in open culture
  • Reduce attrition as you really know challenges and definitely a lot of which you can work on.
  • It gives 360 view in terms of how the teams are progressing.
  • One of the biggest “Glad” item one should have is, your organization is conducting it.

The challenges I see are :-

  • It may become political battle if your team is not mature and willing to go for anonymous survey.
  • Excessive sad mad and glad would unearth issues which are not really problems while make other team members think it’s a major problem.
  • Sometimes very happy team morale goes down as well as when you have opportunity to think about negatives, you feel like writing it and further “law of attraction” does its job.
  • What I written must be addressed and fixed “Myth”. You may not like the tile color in washroom but that cannot be really changed.
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.

Agile Manifesto and Core Principles
 

The agile manifesto says

Individuals and interactions over processes and tools

When I first time read this statement, I was little puzzled in terms of identifying the focus or intention behind this starting point. I had following question in my mind

  • Should we give little/no preference to tools or processes. Or if we do, to what extent.
  • Why is communication is so important? Why can’t we get it done utilizing tools so called ‘Agile Tools’?
  • What does it mean by individuals?

The whole world make use of processes and tools. The tools like JIRA has gotten lots of popularity.  At a time you feel that things can just go right even though there are distributed teams or people don’t interact much. The real truth is agile focus on people, communication and internal interaction.  In order to understand the real intention just replace the word “over” with “before” and it would make better sense. One cannot replace processes and tools completely while the communication gets more priority.  The collaboration, interaction and internal trust makes self organizing teams. The lack of self organizing teams result in ‘Handicapped Agile’.

Working software over comprehensive documentation

The comparison here is with waterfall or traditional development methodology where the customer requirements are documented start to end with huge sets of artifacts. I have personally seen team spending more time in documentation over building software. It is virtually impossible to document every piece of requirement in the beginning for most projects. Moreover the sign off from customer is just a formality as customer is dreaming of working piece over what is there in requirements. The elaboration of requirements itself is complicated and further there are so many unknowns.  The Agile believes in incremental development  and continuous delivery of working software to ensure the work is being done with respect to customer expectations.

It is good idea to have limited documentations while this statement every agile developer has taken it so seriously and developed a myth there should not be any documentation to be created at all.   Having product document, user manual or specifying common issues etc. would help project to run smoother.
Customer collaboration over contract negotiation

There is a common myth what I have seen in most of the projects I have gotten into that is “We don’t need a contract with customer and we would do it as we move forward with development”. This is one of the most misunderstood statement among developers and folks getting on to Agile. We obviously need contract and while the customer involvement gets more priority. Let me give you an example to understand this better.

Assume that you want to build a connector to connect to your IAM product to customer application to perform provisioning. The product roadmap and release planning is over post feasibility. As per release planning we have divided the work into number of sprints say 2 weeks 24 sprints. At this point as we constantly showing the working product to customer, the changes are welcome. The scope creep can be managed in this case is either by removing something from sprint of similar size which is not being worked up or adding that item in future sprints (not the work in progress). This might result in adding one or two sprints to overall 24 week sprint (Possibly we can reduce that while this kind of chances are fat)

Adding one or two sprints or probably more won’t disturb customer as at the end he would have a solid product and moreover the changes are proposed by customer which could be because market dynamics have changes, customer has missed the requirements or could be anything else.
Responding to change over following a plan

The successful product matters over complicated plans. Agile is extremely adaptable and typically go with release schedules while each release comprises of one or more sprints. The water fall model simply follow the plan and any change in requirement is very tough to include and further adds lots of cost to it. The flexibility of managing scope creep makes Agile superior. The focus is always respond to change. I have personally seen 6 weeks sprints have changed to 20+ weeks while customer was really happy as he has gotten what he wanted.

Here you have principles behind Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

There are number of reasons

  • Customer gets confidence by constantly getting the working software.
  • The early time to market adds lots of value.
  • The market dynamics helps to make changes to products.
  • More than 60%+ software projects are scrapped before they are complete. This percentage can be reduced and further if you product is not good enough you got to know well in advance and you can take a call whether you want to continue or stop it.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The changes are always welcome. The customer gets what he wants and it would not hurt developer or company building the software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

You know where you stand and the same is with respect to customer. This is probably the biggest benefit of agile.

Business people and developers must work together daily throughout the project.

The biggest reason for most of the projects failure is the team working in isolation with no clue whether they are on track. Working closely with customer constantly not only gives confidence to customer while at the same time benefits to team to be aligned well with customer with respect to their requirements.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.