Agile Appraisal – What to consider
 

If you are a manager and above in agile work environment and you need to go with appraisal, you might have encountered situations where what to expect from your team members compare to traditional model.  The focus is on collaboration, pairing, individual ownership for self and team. The “Working for team” culture over work for “self” make it more difficult.  One of the recommendation I have for all the managers or individuals responsible for doing appraisals for agile team is to have  a certain percentage allocated to team success in everyone’s goal,  and further how the team collaborates and how well they work together.  The percentage can differ with experience of an agile team member and expectations what you have from your team.

When it comes to individual performance (obviously there is a percentage attached to this as well which is typically little above than team success), I prefer to look at three factors which covers it all.

1. Competence – Demonstrates strong leadership in one or more areas (e.g., technical, project management, process, etc.). Consistently works to leverage skills for team and larger organization success.

  • Breadth and depth of knowledge and skills
  • Problem solving ability
  • Technical, communication, interpersonal, business skills
  • Leadership and innovation, applied to people, processes, and projects

2. Contribution – Someone who has a lot of initiative, is a leader across the organization, and has outstanding productivity.

  • Ability to meet commitments
  • Overall productivity and volume of output
  • Early communication of problems and contribution to workarounds that meets business goals
  • Versatility – willingness and ability to adapt to new tasks
  • Teamwork – willingness and ability to help others
  • Leadership skills such as architecture, project management, change management, communication, and mentoring
  • Ability to motivate others, manage self, and demonstrate initiative.

3. Value to business – This is very critical. What kind of value you are adding to business. There could be high competence and contribution to build a product while ROI (Return on investment) should never be ignored.

  • Knowledge and skills as mapped to needs of the business
  • Extra points here for unique skills we need

Every agile member should ask three questions to himself/herself frequently

  • Am I learning?
  • Am I contributing?
  • Am I making a difference?

The manager should ask the same questions to himself/herself and same for his team. If the answer is no then appropriate development goals must be planned and discussed.

The biggest goals for a manager should be in while managing agile project should be

  • Sprint success
  • Continuous Improvement
  • Constant Learning
  • Building Self Organizing Teams

 

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.

Why do we need tasks? What is the need of Planned, Actual and Remaining hours?
 

I have repeatedly heard from teams that we have done estimation for stories in terms of story points or t-shirt sizes hence now why do we create tasks or if at all if we create tasks why do we add hours to tasks?  Add to that what is the need for specifying actual vs remaining hours every day for each task. The story is good enough to know what is to be done so why look at tasks. The benefits over challenges are much bigger and you can be truly convinced when you attempt it.

The recommendation is to have tasks created for each story.  Typically individual task should not be more than a day. If that’s the case, break it down further. Almost every task can be practically broken down to meet this criteria.  Once tasks are created, each task should be tagged to approx. hours needed for the same.

While creating tasks not just restrict yourselves to functional requirements while focus on following but not limited to

  • Non Functional Requirements (Performance, Security, Scalability, compliance, accessibility, maintainability etc. )
  • Dependency
  • Constraints
  • Acceptance criteria

The best time to create task is pre-grooming which is done few days ago before actual sprint planning/grooming.  It is my personal recommendation to get as many tasks as possible before you go for actual grooming. You can always convince team how you have come up with these tasks.

I am listing some of the core benefits of creating tasks, assign hours to each tasks during planning, smaller tasks and further constantly entering actual hours and hours remaining

  • The tasks add lots of clarity to story. I always advice individuals to create tasks before actual planning meeting. The pre-grooming done in advance in earlier sprint is when tasks should be created. This results in better estimation further result in better planning.
  • It is always simple to do individual smaller tasks over doing entire story. It is undoubtedly faster better and cheaper option.
  • Having tasks for individual story make it very easy to share your story work with other team members.
  • The hour assignment for each tasks helps in predictability of complete the tasks. The risks can be mitigated much earlier or in many cases it can be avoided during planning itself.
  • The actual vs remaining helps to come up with burndown chart which is one of the core artifact of agile teams. You can always have burndown based on # of items closed or velocity burned but that doesn’t give clarity and adds up little or no value.
  • Adds lot of value to individual accountability as it gives clear picture in terms of who is doing what and whether he/she is taking longer or getting it done early. This is one of the main cause many agile members are not inclined to go and add that much of details. The thinking of to become accountable is not a good idea is in reality bad for developers. More than an organization loss, they are killing their careers.
  • Small victories (after completing each tasks) gives motivation to individuals.
  • You are directly or indirectly reducing assumption on stories resulting success chances getting better. “Assumption is mother of all screw ups”. You can’t run away with assumptions while reducing the numbers helps you to do more.
  • The question which you might ask your stakeholders at later stage is typically unearthed well in advance.
  • In majority of cases better sprint success rate by having tasks and further hours (Planned, actual and remaining)
  • The nonfunctional requirements (security, performance, scalability etc) are listed in advance and these are being considered while planning
  • These NFRs, code reviews, testing etc are never missed. Typically POs encourages to list only requirements those have business values while I always recommend to write all the tasks which you are going to do.
  • The dependencies, constraints are identified. Moreover the acceptance criteria is well covered. The tasks suffice the need for missing SRS (Software Requirement Specifications) in agile projects.
  • The productivity is bound to be better in addition to quality. I have personally worked with tons of teams and experience the same.
  • Better bonding within team as things are BETTER organized.
  • You can better calculate matrices like productivity, cycle time, utilization etc.
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.

What are Scrum Roles and Responsibilities
 

The Scrum roles are

Product Owner – PO is a key stakeholder in an Agile project. He/She is responsible for defining or detailing the vision, understanding organization goals and ensure to align project goals with it.

  • Defines the features and stories of the product.  Elaborating requirements, clarify doubts and clearly stating acceptance criteria.
  • Review every functionality and accept or reject the work accomplished by the team.
  • Responsible for release planning and further prioritize the work.
  • Owns product backlog, release backlog.
  • Remove functional impediments and constantly answer product related questions to the team.
  • Constantly talking to other POs to align product/project changes with business unit/organization goals.
  • Responsible for the return of investments.

Scrum Master

  • This is management function of Scrum.
  • Facilitate the daily standups.
  • Setting up retrospectives, pre-grooming, showcase and other meetings.
  • Remove impediments or obstacles for all kinds (technical, functional, resource etc.)
  • Co-ordinate with POs, Team, Manager and all the project holders.
  • Ensure team productivity and closely working with them to ensure quality requirements are enforced.
  • Ensure team understands the processes and adhere to them.
  • Protect team from external interferences and interruptions.

Team Member

  • Responsible for actual implementation.
  • The recommended size is between 6 to 10 people. The best practice is to have 7 member team.
  • All the members are expected to be full-time.  The exceptions could be DBA or some specialized skill needed on a temporary basis.
  • Proactively identify ways and opportunities to improve the performance of the team and constantly get better.
  • Are set of programmers, DBAs, tech writers, technical experts, domain experts, independent testers etc.
  • Must be self-organizing.
  • Constantly communicate with the team and ensure to meet sprint goals.
  • To share all information in daily standups including “work in progress”
  • To support each other. Most importantly consider sprint goal a priority over individual goals.
  • Avoid accepting outside or extra work without consent from team.in