Confusion of Employee Performance Appraisal in Agile

Financial year end is near. Your organization has kicked off the yearly employee performance appraisal process. As a manager, what is your situation?

Mr. Sundaram is a confused manager today. He has been working for a Bangalore based software development company called SinsforSystems for last 8 years. He has been asked to provide performance stack-ranking (5, 4..1) for all his reporters, across all grades (E1, E2, .. E5), normalized across 3 teams he is heading, with entire data fitting the Gaussian distribution (The Bell Curve) across all dimensions.

Now, employee performance appraisal is the yearly process in SinsforSystems and Mr. Sundaram has been the champion who has mastered the art of ethical-performance-rating. People have never challenged his judgment and evaluation acumen. He has been transparent and objective in his employee performance ratings. His appraisal practices religiously embraced MBO(Management by Objectives). He is a smart technical manager who sets yearly goals and objectives for each of his subordinates at the start of the financial year and evaluates them sincerely and perfectly at the year end. No exception catching required. 20% of people reporting to him are always top performers, 20% always bottom performers and rest are ‘good performers’. He is known for successfully giving constructive feedback and setting right directions and goals for those rated as ‘good performers’ to get them into the ranks of ‘top performers’ during next appraisal cycle. Interestingly, during every yearly employee appraisal, he still manages to get his 20% top and 20% bottom ranked employees. The genius he is, it takes him just 1 hour to complete all the employee ranking papers, without missing the Big boss episode. He has always been an involved manager!

But, this year performance appraisals are a lot different. SinsforSystems has ventured into an agile transition program and Mr. Sundaram has been lately baptized with holy agile water. He has attended few agile courses, conferences and organized classes. He has been actively engaged in agile ceremonies – Sprint planning, reviews, retrospection, daily scrums. He has been through lessons on self-organization and autonomous team building. He has done some self-reflection on his role in agile teams and worked with agile coaches in team building and agile roles fitment exercises.

He is not sure if the existing techniques of rating and ranking the team members performance in isolation are going to work this time. He has seen a lot of team member’s involvement, communication has improved, team members are more aware of what is happening in the team, they know who is contributing on what, and how much. This scrum implementation has bought some noticeable awareness on team visibility, contributions and effective deliverables. Yearly individual objectives and goals they have set do not make sense to him in agile context. E.g. one of the architect’s in the team has a goal of “Creating high quality complete design before development”. Team is now forced to work on more iterative design and development within the sprint. His goal is somewhat redundant. Similarly, what is tracked now is sprint deliverables not individual deliverables. He can only give limited credits to those high-profile-experts in the team, who in the past, were recognized for quick completion of tasks irrespective of whether anything makes into the sprint’s potentially deliverable completion list or not. He sees the importance of measuring knowledge building and sharing, mutual trust and team work, re-work, continuous improvement through retrospection, code quality, adherence to agile principles, practices and disciplines, but he does not know how he can change these yearly performance goals for every individual to reflect these much required changes. Does he really need these individual goals now or does he need few team goals in addition? How will he measure them? Does he a need 360 degree feedback from team?

Mr. Sundaram is sure it’s a different appraisal this year. But, he cannot do much. Human resource department has never been part of the organization agile initiative. They do not know how agile initiatives impact employee’s yearly appraisals, they never planned or modeled for it.

What will Sundaram do?

Do not get lost in agile ceremonies – Create continuous improvement teams and communities in parallel

Agile programs in organization start either in public or stealth mode. They are either, all-teams-together or pilot-team-only agile programs. ‘Public agile initiative’ has team or organization announcing its agile initiative with a big organization wide fanfare. Stealth mode programs are executed with limited or no noise, with one or more specifically identified teams. Agile programs can also vary depending on the number and intensity with which different agile practices are adopted. Some agile programs may start with few agile practices, others may prefer wholesale process adoption for experiencing the synergy of practices done together. If the public-mode agile initiative is started as an enterprise scale program, the pressure of getting agile transition successful mounts on the stakeholders – the risks and impacts are higher for enterprise level transitions.

Agile programs start with adoption of few commonly known practices by teams. Scrum adoption will start with user stories backlog creation, sprint planning, user stories acceptance review, daily stand-ups, retrospection etc. Teams will receive their first few training lessons from agile coaches or practitioners; who will train them to get these practices adopted immediately. It is important to follow these practices consistently on each sprint because they provide the needed structure for iterative and incremental development. They are important for tracking, communicating and executing in agile iterations. They are our agile ceremonies!

Agile stakeholders, with short and limited vision, soon get lost in agile ceremonies. They think that the agile transition job is done, and results will follow once these practices are adopted. In reality, it’s just the beginning of an agile journey. Inexperienced leaders and managers review and enforce on-time execution of these celebrated events. The issue scope, time and speed control directives – ‘Sprint planning should be complete by Monday first half’ , “We would like to see all retrospection done by Friday morning before the end-of-sprint”, “How many story points got completed compared to other teams”, “Can we increase number of user stories getting started or accepted in a sprint?”. They think, only work required to complete the agile transition is operationalizing these activities consistently without any failures.

Well, when we focus too much on these ceremonies and start using incorrect measures to judge the progress of agile initiative, soon the system gets skewed to reinforce activities which are not in interest of agile improvements. Management rejoices; they see their success in implementing practices as-planned. They are getting their reports on time; they know what is planned for each sprint deliverables, and who is working on what. They can hold the team responsible for not delivering on the planned items for each sprint, and they can do it more often in agile.

My advice to agile stakeholders is — ‘ground yourself’. You have just launched an agile rocket in space; you have big tasks ahead to get it into a right orbit, and then drive it into an unknown but continuously improving territory to reap real benefits endlessly. Agile leads need to initiate continuous improvements in practices, technology, tools, values, principles, competencies, collaboration, communication etc. within teams to drive agile efforts to next level.

Following are some of the questions agile leads can ask (in no specific order) to trigger continuous improvements within teams:

What is the commitment level of team for agile (scrum)? Do they just comply or commit to agile?
Have all teams adopted scrum?
How teams feel about agile initiative and different way of working? Do they have objections or resistance to scrum? Have we provided teams the open environment to voice these objections?
Do team member understand and embrace agile values and principle?
What has improved? What is the improvement in quality, productivity, predictability and cycle time?
Are scrum teams self-organized?
Is your product owner involved?
What is the status on emergent agile simple design, test automation and continuous integration?
What are the continuous integration challenges?
Are you practicing more matured agile practices like Test-driven-development and Behavior-driven development? Are these XP development practices yielding noticeable results?
Are your scrum masters trained? What other training are needed for the team?
What is expertise of the team in user story driven development?
Do you have a checklist for “Done-Done of user story” and “Ready-Ready for user story”?
Has the code and design quality improved? How we can improve it – TDD, refactoring, reviews?
Do your teams know how to create iterative, emergent design or you still do big-design-upfront within sprint?
Are sprint retrospection leading to improvements?
What needs to be changed in your values, principles and culture for better agile adoption and continuous improvements?
Do we need different measure for agile?
What are the impacts on external teams (facility, HR)?
What needs to be done to improve communication and knowledge sharing?
Are your practices supporting agile values?
What are the challenges of distributed teams? Are we able to scale scrum?
What are the wastes in our agile development and how we are eliminating them?
Are we always working on most important items?
Are we able to complete testing within each sprint?
Are we able to handle sprint interrupts?
Are the teams adequately staffed with right skills sets?
How are code reviews done?
What is the expertise level for each adopted practices?
Are we using right tools for the agile practices?

Initiate continuous improvement programs to improve the agile journey. Identify, plan and solve problems which are hindering agility. Create a recognized ‘agile transition committee’ (ATC) responsible for identifying, creating, managing and supporting the improvement plan. This can be a team of key stakeholders responsible for agile transition with agile coaches, experts and enthusiasts. The primary function of this team is to create a backlog(like a scrum product backlog) of actionable, improvement items, ensure that they are allocated for actions and all necessary support, resources, and guidance is provided.

ATC can facilitate creation of ‘Continuous improvement task teams’ (CITT) to work on specific improvement items. They can be full-time or part-time teams. CITT can be a formal or voluntary team. Voluntary teams have an advantage of commitment. They can build communities around the improvement items to re-enforce and build expertise for continuous improvements. They are committed to addressing cross-cutting concerns. CITT can also be one of the existing scrum teams including the tasks of improvement plan in their iteration backlog.

CITT can target one improvement at a time and research, observe, model, implement, promote and transfer that across scrum teams. CITT can run their scrums to work on a continuous improvement backlog items. ATC team should facilitate overall improvement program and prioritize the improvements for value added results.

Continuous improvement is the engine on which the agile initiative survives and grows. It’s the heart of agile. Without continuous improvement, the agile efforts will not succeed. Organization gravity will kill stagnant agile initiatives.

ATC team will work like a scrum team with an agile improvement backlog; delivering improvements every iteration. They will also act as a product owner for ensuring improvement backlog is prioritized, groomed and ready to be consumed by CITT.

Create and manage continuous improvements teams and communities within organization to fuel your agile initiatives.

Stop Micromanagement Epidemic – Lessons for Micromanagers

Micromanagement has severely impacted people and teams in the organizations.
It’s the most ubiquitously prevailing management sickness in the organization. Micromanaged environment kills creativity and productivity, bringing down the organization capabilities to produce quality products. If your team is on the agile journey, it’s important for managers to be aware of the micromanagement activities. It’s not easy for managers to understand, recognize and take necessary actions to eliminate the micromanagement behavior. It gets into your management style like a virus, severely hurting your subordinates, team, colleagues and yourself. It is important, we identify micromanagement activities in the organization and plan for it’s remedial.

I have been compiling some thoughts on micromanagement for a while. It turned out to be a long article at the end.

I have divided this article into following sections:

1. What is micromanagement?

2. People and organization impacts of micromanagement: Big cost to the company.

3. What do micromanagers do?

4. How micromanagers justify their act?

5. Why we do micromanagement?

6. Why we let go micromanagement?

7. How micromanagement affects micromanaged victim?

8. Micromanagement cycle – The micromanagement trap

9. What can organizations do about micromanagement?

10.What can you do if you are micromanaged?

11.What can you do if you are a micromanager?

12.Micromanagement vs. Effective Management

What is micromanagement?

Micromanagement is about “Excessive involvement by a manager with an employee in regards to his performance. In short, it is imposing work standards and behavior expectations that meet the personal needs of the manager, not the employee, or the organization. It is to control a person or a situation by paying extreme attention to small details“. Courtesy – Jim Rooney “From micromanagement to mentoring”

Micromanagement is the inability to trust or relinquish control to others and is a manifestation of fear and insecurity. In micromanagement, the manager not only tells a subordinate what to do, but also dictates that the job be done a certain way, regardless of whether that way is the most effective or efficient one. Manager will engage in behavior that may be in-protective of their division’s interests, or their personal interests, but harms the organization as a whole.

People and organization impacts of micromanagement: Big cost to the company

1. Poor quality of deliverable from team: This is a vicious circle, which leads to more micromanagement from micromanager to get more control.

2. Low team morale: Individual heads are down due to daily fire-fighting. Team morale suffers as people are not engaged and feel low esteem.

3. Impacts on other teams and employees: There are grape wine and dis-engagements talks all around. Other team members will avoid helping or joining micromanaged teams. It also leads to conflicts between individuals and teams.

4. Absenteeism from work: Who would like to face a micromanaging boss every morning?

5. Feeling of dis-empowerment: You are a puppet executing on the boss’s daily agenda. Are you building something significant or blindly executing on orders?

6. Low confidence: People operate at low confidence due to fear of failure and resulting humiliation.

7. Suppression of innovation and loss of creativity: Innovation thrives on conducive and creative environment. Micromanagement kills it!

8. High employee attrition: Knowledge that goes straight to competitor. Remember, people leave their managers more often their companies.

9. Loss of productivity:People who are micromanaged lose interest. It affects their productivity and effectiveness. Will you contribute if you know that the credit of your hard work goes to someone else?

10. Loss of corporate knowledge: Organization knowledge system weakens with people leaving the company.

11. Project failures: High cost, delayed deliveries, poor quality and low productivity leads to project failures.

12. Loss of trust between organization and employees: Here is this manager making your life hell every day. What is the organization leadership doing? Will you trust the organization supporting micromanagers?

13. Delayed decision making: All approvals go through the micromanager. It is he who makes all decisions. You are supposed to wait for that trickle of important decisions flowing from micromanager’s office, blocking everything.

14. Restricted information flow: Communication structure and flows are important for team and organization decision making. Filtered and tempered information leads to delayed and ineffective decision making.

15. Walls of functional silos: Departments, functions and groups lead by micromanager’s work in isolation; embracing ‘throw over the wall’ practices.

16. Goals and objectives are forgotten: Individual goals are not aligned with team, function or organization goals. Satisfying the micromanager becomes the only primary goal for subordinates.

17. It grows as an organization style: Virus! – Micromanagers breed more micromanagers. You want to pass on your pains to others.

What do micromanagers do?

Following are common acts of a micromanager:

1. They exercise raw positional power, and use their positional authority to assert things.

What subordinates hear from micromanager?

● “I am the manager here”

● “This is ‘My team’.

● “I will monitor”.

● “You report to me”

● “I will tell you how to do it”

● “I want this … by this date… “

● “I made it clear to you…”

● “Why it was not done the way I dictated”

2. They dictate time for tasks to subordinates. They don’t trust people to assess their own work; so they impose priorities and timelines which no one understands.

What subordinates hear from micromanager?

● ‘I want it by end of day today’

● ‘Work for 50% of your time on this today’

● ‘Give me the estimates now…’

● ‘I can finish it in few minutes. Why you want this much time…’

● ‘I do not see any progress today(even in last few hours)’

● ‘I have committed end of day Friday for delivery’. So do it!

3. They control how work gets done.Work always needs to be done the way micromanager wants it. They do not care to develop standard practices and processes.

4. They run their own system of processes and practices, completely misaligned with the project, functional and organizational practices. They call it ‘their long experience of doing right things in right way’.

5. They always focus on ‘How to do a task?’ instead of ‘What to do in a task?’ They dictate the steps of the task rather than the form of the results.

6. They require undue approvals. They allow no one to move forward without their approval even on routine or time-sensitive matters. Everything needs their approval.

7. They ask for excessive status updates. They demand frequent, unnecessary reports. They require reports that focus on task activities over outcomes.

8. They resist delegating,or delegate small un-important tasks or take back delegated tasks and re-assign often. Instead of letting subordinates solve problems and challenges at hand, some managers return those tasks to their own domain to exercise dominance. This brings discouragement to team members working on the tasks.

9. Delegation without authority:If they delegate they watch every details- suffocating the team. Delegation without authority and accountability is a ‘Dirty delegation’.

10. They create dis-empowered team. They do not encourage empowerment of team members, which means lack of control to them.

11. They control information. They filter information for personal benefits from their subordinates or their bosses. They temper with organization communication structure and provide limited information for decision making

12. They are always found around subordinate’s desk monitoring over the neck.

13. Unwanted status checks:They drop unwanted emails to check progress. Example: Those, after lunch status check emails in your inbox.

14. They discourage others from making decisionswithout consulting them. They get irritated when subordinate makes decisions.

15. They blame others for failures. Their defensive routines are always at work. They take credit for positive results and shift the blame for negative results to their subordinates. The regularly criticize their subordinates.

16. They create their own performance measuresfor project, tasks and individuals. These measures are not aligned to functional goals, objectives and responsibilities of subordinates. They surprise you with their measures.

17. There is no transparency in how tasks are done and measured in micromanaged environment. Thriving in chaos protects their personal agenda.

18. They assign tasks not responsibilities.

How micromanagers justify their act?

Micromanager is blind to his micromanaging behavior, so he justifies whatever he does in his own way, re-enforcing his own improper behavior.

1. They call it ‘Attention to details’.

2. They say they are ‘Involved and hands-on managers’.

3. They claim it as ‘Positive aggressive attitude’.

4. They say, ‘they get results by micromanaging’.

5. They interpret the result of micromanagement experimentation as proof that, without his constant intervention, his people will flounder or fail.

6. They glorify short term results. ‘I made it working otherwise…’

7. They say they are fixing inefficiencies of the system quickly and firmly.

8. They say they are “structured”, “organized”, and “perfectionists”.

9. They educate their subordinates to adopt their style and practices.

10. They say they are recognized for their efforts.

Why we do micromanagement?

1. Personal traits

· Control-obsessed: Controlling subordinate behavior gives sadistic satisfaction.

· Personality of manager

§ Shaped by her own experience with micromanagement from his mentor.

§ Obsessive–compulsive personality disorder.

§ Supreme leader disorder – self-proclaimed supreme team leaders experience extremely low self esteem, ever worsening inferiority complex, and zero respect for their teams.

● Inability to trust others.

● Emotional insecurity.

● Feeling of control and superiority: Hierarchical organizational systems, and power allocation with position, leads to the feeling of superiority for micromanagers.

● Tendency to create aggressive individual image for themselves in the organization.

2. Lack of knowledge and skills

● Lack of competency and creative capabilities.

● Limited skills.

● Limited training.

● Lack of knowledge on organization and team’s behaviour.

3. Organization culture and management

· Organization culture: If the organization has a culture of micromanagement, it infects at all levels. It comes straight from top.

· Style of management of senior, influential people impacts other management level.

· Instability of managerial position. If the position or job is at risk, people tend to do micromanagement.

· Peer competition can lead to getting into lot of task and project details leading to micromanagement.

· Promotion and rewards based on experience rather than skills can lead to micromanagement. Experience people focus on exercising more control rather than building knowledge and learning.

· Business and work environment

§ Misfit for the job – If the manager is not good fit for the assigned job and he cannot meet the demand of the situation, he will tend to control all tasks and work assignment to get visibility and control.

§ Time or performance pressure without right skills can lead to micromanagement.

· Unplanned project schedules can also lead to micromanagement. Micromanager may not know the current capacities and capabilities of the team

· Lack of capacity in teams results in more involvement of managers on tasks which can lead to more scrutinized work.

· Skills of subordinates also lead to micromanagement by manager.

· Lack of tools. If the team do not have right tools they tend to spend time doing repetitive tasks. Long delayed task get more attention.

Why we let go micromanagement?

1. We are afraid of becoming the next target. Fear of job and insecurity leads to our submission to micromanagement.

2. Conflict avoidance: We are all basically afraid of conflict, we’re endowed with a fight or flight response, and we just want it to go away. No one wants to get into the mess, so we avoid it.

3. Lack of skills and knowledge to do better job. If people have limited skills to do their job, they avoid getting pointed out for productivity and effectiveness concerns.

4. No access to higher management to discuss issues and concerns. If there are no channels to discuss the micromanagement issues at higher levels, people suffer.

5. Selfish interest also leads you accepting micromanagement activities. May be you are due for promotion or rewards and you think it’s better to let the situation go as-it-is, rather than raising concerns.

6. Lack of trust in organization capabilities to change things. If you believe that organization leaders will not act, you will not bring the concerns to their notice.

How micromanagement affects micromanaged victim?

1. People are publicly humiliated.

2. The victim is shunned and punished for speaking out, and often ends up being forced out.

3. People lose focus on work.

4. They become disengaged.

5. They lose confidence to execute work independently.

6. Their performance and productivity suffers.

7. They get frustrated with day to day micromanagement pains.

8. They tend to get timid and tentative.

9. They avoid taking responsibilities.

10. They avoid making decisions and leave to micromanaging boss to decide for them.

11. Their professional progress stops.

Micromanagement cycle – The micromanagement trap

Micromanagers follow a pattern while exercising their micromanagement wills.

1. Micromanagers target people mostly one at a time.

2. They victimize them regularly.

3. They force them out of the team and organization.

4. Victims are replaced by incompetent people so micromanagers can exercise more control with no resistance.

5. Micromanagement cycle continues.

6. Micromanagers grow; Organizations suffer.

What can organizations do about micromanagement?

1. Identifying and recognize micromanagement in the organization.

● Spot it!

● Check for complaints. Encourage people to report micromanagement.

● Look for teams with high attrition, and low productivity; a micromanager might be at work.

● Study how teams work together; conduct a survey of their job satisfaction and begin tracking their productivity.

● Look on long term measures rather than short term results. Example: if the product releases are happening on time but leads to lot of technical debt, people are not involved or committed to quality and continuous improvements.

2. To address the micromanagement issue, be decisive, and lay out a clear plan-of-action for micromanager with consequences for not following through.

3. Once recognized, intervene, and act as early as possible (no matter how uncomfortable it is).

4. Limit the authority of the micromanagers to reduce the micromanagement impacts.

5. Institute a mentoring and leadership program that can re-align micromanagers with your organization’s values.

6. Hire right competent people – people who can solve problems, not micromanage them.

7. Institute right values and principles and continuously spend time in improving company culture. Lean and agile principles adoption can help in controlling micromanagement.

8. Drive out fear. Encourage an open door policy which will enable your employees to work and communicate openly without fear of repercussions, and more importantly, leave no room for manipulations.

9. Establish chain of responsibilities across the value chain. Ensure that the tasks is considered done when the next person in chain is able to consume the deliverables. This will lead to end to end responsibilities requiring inter-team communications and collaboration and less chances for micromanagement.

10. Grow communication structure and channels for transparent and open communications in the organization.

11. Encourage teams for self-organization with managers as mentors and coaches.

12. Get help from external coaches and mentors to help the teams and micromanagers.

13. Rotate work and team members.

What can you do if you are micromanaged?

1. Find a new Job. Is it the only solution?

2. Help your boss to delegate to you more effectively by prompting him to give you all the information you will need up front, and to set interim review points along the way.

3. Volunteer to take on work or projects that you’re confident you’ll be good at. This will start to increase micromanager’s confidence in you.

4. Make sure that you communicate progress to your boss regularly, to discourage him from seeking information just because he hasn’t had any for a while.

5. Concentrate on helping your boss to change his one micromanagement habit at a time.

6. Understand your manager’s role, responsibilities and information needs. Help him meet his goals.

7. Develop skills and collect data to plan project schedules and project deliverables with higher confidence level. Avoid estimating tasks where there is no data or experience.

8. Forward books, articles, links to blogs on leadership and team management and other stuff to your boss.

9. Don’t let your supreme team leaders get on your nerves. Don’t let them catch you off guard.

10. Document everything!

11. Exercise patience and resolution to change and improve.

12. Identify other communication channels to talk and seek help on micromanagement. Don’t let it go.

13. Work with your peers and create constructive plan to reduce micromanagement from your boss.

14. Empathize with you micromanager boss. Understand his job and offer help proactively.

15. Identify patterns pointing to situations when the micromangement behavior activates.
Solve the problems in advance and help him.

16. Earn respect and confidence and then communicate about the micromanagemnt aspects to him.

What can you do if you are a micromanager?

1. Realization and recognition of micromanagement: Realize and recognize that your controlling-ways will probably hinder your own career. This is the first step to bring required changes for your micromanagement style.

2. Realize that you are a micromanager and your style is affecting individual, teams and the organization.

3. Understand the difference between involved-manager and a micromanager. Just because you are seeking fine details about tasks from the individuals does not mean you are ‘involved’. Involved-managers enable problem solving with just enough control. They are facilitators not dictators or directors.

4. Do not ask for excessive status updates. While knowing the status of project and tasks is important, asking for constant updates on work status can limit productivity. Updates that are too frequent leave less time for true progress. Instead of over-managing each task of the project or assignment, it’s important to let employees spend time developing their own ideas and knowledge.

5. Taking back delegated tasks after you’ve assigned it to team or individuals, or going back on your word can be a sign that you’re a micromanager. Let subordinates solve problems and challenges at hand; help them by providing support for problem solving. Do not move tasks back to you (without real reasons) after assignment.

6. Forget that you can always do all tasks more quickly and in a better way yourself. Committed, skilled teams always deliver more than the individuals. Work on building team capabilities and competencies, and do value adding contributions to the work individual and teams are doing.

7. Work hard on delegation skills. Delegate, and hold people accountable. Delegation without accountability is ‘dirty delegation’

8. Enable individuals to make their own informed and evaluated decisions. Requiring others to ask your permission to perform tasks under their control is a way to inhibit progress. While being consulted on tasks is normal, do not make it mandatory to seek your approval on all tasks even when they are in employee’s realm of responsibilities. This controlling behaviour strips subordinates of decision-making power, even when the decisions made are within the sphere of the subordinate’s responsibility or authority.

9. Never filter or control information. Enable free and transparent information flow by building right communication structure. Do not get involved in filtering or tampering information channels. Encourage information flow to subordinates – Keep them informed.

10. Do not send unwanted emails seeking unnecessary status on tasks.

11. Talk to your teamregularly on your management style. Get their feedback.

12. Build relationship with subordinates. Good work relationship will build trust and reduce micromanagement.

13. If you are not confident of the subordinates capabilities to deliver, focus on the ones with the most potential, and learn to delegate effectively to them.

14. Encourage ownership by subordinates.

15. Trust your team to develop and deliver.

16. See long term benefits – The big picture. Do not exercise control to seek short term benefits. Spent time in building teams and capabilities.

17. If you have identified your acts which might have caused problems to subordinates, apologize and change.

18. Know when you need to get involved and when to get out of the way.

19. Clarify the outcomes of the tasks to subordinates. Manage the outcomes not the process.

20. Set the clear communication plan.

21. Master the art of questioning and listening– Ask, not tell people.

22. Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.

Micromanagement vs. Effective Management

Click to view ‘Dave Crenshaw’ talk on differences between effective management and micromanagement. http://www.youtube.com/watch?v=DmtslJXYrQU

Here is table differentiating a micromanager from an Effective-manager based on the above presentation

Micromanager	Effective-manager
They are like less effective ‘activity directors’.	They are ‘effective leaders’.
They focus on how things are done and want the prescribed way to be followed.	They focus on results. They discuss the end results, constraints, issues, expectations, paths and then they give people flexibility to think and create.
They tell people ‘what to do’.	They tell people ‘why we are doing something’. They explain and discuss the reasons behind the task at hand.
They want everything now. They want to get all things done within the determined timelines. Often defined by them without much consideration of existing constraints.	They focus on ‘when’. They work with their team to define the timelines.
They want compliance against the policy, inflexible practices and procedures.	They focus on growth and continuous improvements.
They look their team members as subordinates.	They work in teams.
They are always hovering around their subordinates for status.	They hold people accountable and allow them the freedom to do what they think is correct.

Get Started on Test-Driven Development!

Test-Driven Development (TDD) has been a proven and powerful design and development techniques to create high quality product in agile environment. Agile teams embracing TDD thought-process to design and implement their product features have realized significant improvements in code and design quality. TDD increases reliability in software development. TDD driven teams are more likely to meet their User story Done-Done criteria’s for a sprint. They will be able to reduce re-work waste while development, and maintain the flow during iteration. TDD development is always guided and supported by tests. Above all, TDD approach leads to beautiful code – testable, maintainable, extendable and readable.

Following are some experiences (with limited explanation) of TDD practicing agile teams:

1. Improved Code Quality

TDD helps in creating code that flows better; code that’s easier to understand and use; code that expresses what it does and why, instead of how it does it.
TDD driven code is clean and lean. Minimal code with optimum design gets written when team develop TDD way.
TDD ensures high quality maintainable code. Well maintained code leads to low re-work and less efforts when extensions and modifications are required on exiting code.
TDD produces testable code by making the code cleaner, simpler and less complicated. Production code is always testable because it is written in confirmation with the test code.
TDD improves the readability of the code. Developers continuously re-factor the code to make it more readable.
TDD reduces programming errors. Since the code is continuously tested, programming errors are reduced.
TDD helps us write thoroughly tested code, and evolve our code with the best incremental design possible at each stage. Test written before the code helps developer to experiment and evolve the code in right direction with controlled quality.
TDD helps in avoiding production code explosion. Unnecessary redundant production code does not get written. We build the simplest thing that is needed now and discourage speculative development.
TDD leads to testable, maintainable test code along with production code. TDD drives continuous re-factoring of test code along with production code, which leads to high quality, low maintenance test code.

2. Emergent Design and Architecture

TDD leads to good emergent design. It helps developer to think about the code from the perspective of other (existing and non-exiting) code that will use it. It promotes emergent incremental design. Design emerges as production code is written in incremental steps, guided and experimented with tests.
TDD guides development to right design and functionality Developers can avoid coding big requirement and design at one go. Requirements and design gets translated incrementally into well behaved code.
TDD discourages “Big Design Upfront”(BDUF). It gives opportunities to do design changes incrementally, while developer codes the feature.
TDD simplifies the components and object design by simplification of association and relationship consideration between objects.
TDD helps in avoiding over-engineering of system design. Short feedback test loops reduce the traditional bulk implementation approach.
TDD provides continuous feedback to drive improved implementation of design with executable tests.
TDD design is usable and always testable.
TDD enables creation of short composed and cohesive methods and classes. Composed methods are short and easy to test-methods which perform one single identifiable task.

3. Agile Testing with Quality Test Code

With TDD, tests “Do get” written. No postponements.
TDD helps in building a suite of repeatable regression tests as we develop the product code. Regression testing time is reduced significantly with well-designed tests.
TDD leads to high and effective code coverage for unit tests.
TDD coded tests become requirement specification documents – ‘Test as Specifications’. Test serves as documentation for understanding the implemented product features.
In TDD enabled environment, there are no unit test explosion. Unnecessary redundant unit test don’t get written.
TDD helps in ‘testing the test’ to ensure effective unit tests are getting developed.
Unit test written with TDD approach are well re-factored and maintainable.
Tests written through TDD will have fewer bugs.
TDD drives implementation of design with executable tests.
TDD tests are simple and focused on required and essential functionalities only.

4. Agile Software Development Practices Improvements

TDD enables “Programming by Intention“. It makes the developers intention clear by focusing on the actual requirements.
TDD enables iterative, incremental and reflective development and testing with short development cycle – feature by feature.
TDD helps us write better software faster.
TDD leads to test infection – development becomes test infected.
With TDD, user stories acceptance gets coded before the actual implementation. It helps in creating executable test suite and leads to “Test as Specification”.
TDD increases collaboration with Product owners. TDD developer is quickly able to test different viable options providing early feedback to product owners on the user stories. It will lead to better and more complete acceptance criteria’s for user stories.
TDD get the User stories closer to definition of “Done-Done” by ensuring all acceptance test cases have been coded and have existence in executable form.
Code re-factoring is not left for the end. It is done as part of development.
TDD enables continuous collaborations between developers. Developers develop empathy for other developer’s code in the team. They tend to collaborate early to clarify the integration and dependency needs.

5. Creative, Thoughtful and Fearless Developers

TDD enables developers to experiment with design and implementation options by continuously simplifying code and design changes. Developers can make quick changes while developing the code; they can test it in parallel, and gauge the required feasibility of design and code. Tests acts as safety-net for code experimentation; enabling developers to be more creative.
TDD focuses the developer on acceptance criteria’s of the user story.
TDD helps developer to code without fear. Tests provide the safety-net and act as a baseline for improvements. Developers become fearless to experiment and improve the code and design quality.
TDD exposes a gap in understanding of the developer about the functionality. Since the code is developed incrementally, guided by tests, requirements gaps are identified and filled quickly.
TDD developer does more and better code re-factoring.
TDD focuses the developers on the incremental requirements detailing and implementation; avoiding quick, thoughtless code development.
TDD limits and guides developer assumptions – Note: assumptions build on assumptions. Assumptions verified through tests helps in better decision making by developer. Design assumptions are only followed when proved by passing tests.
TDD simplifies complexity handling for developers. Incremental development approach of TDD helps in simplifying the complexity inherent in large batch development by continuously providing the feedback loop to developers.
TDD focuses the developer on what is absolutely needed right-now, then making that tiny piece work, and finally cleaning up any mess she might’ve made while making it work, effectively keeping the code base healthy.
TDD leads to increased developer learning and understanding of requirements!
TDD developers are more confident and creative in design and implementation.
TDD developers are always in control and at fun!

Attending ‘International Conference on Agile and Lean Software Methods’

I am travelling to Bangalore tomorrow for ‘International Conference on Agile and Lean Software Methods‘. Hope to have great time there. Conference is full of important speakers – Craig Larman, Mary Poppendieck, Rebecca Parsons, David Hussman, Fred George, Jeff Patton, Jez Humble, Linda Rising, Neal Ford, Venkat Subramaniam.
Looking forward for a great time in Bangalore!

Managing the iteration Flow–Getting Ready-Ready for user stories in an agile iteration

Agile team needs to get their user stories ready for development before they can be picked for implementation in iteration (Sprints of Scrum). Un-groomed, un-prepared stories, prioritized for implementation in iteration, waste development cycles, and diverts team’s focus from the planned iteration activities and tasks.

Agile team – Product owners(primarily responsible) and development team members, work on user stories grooming in advance, to ensure that by the time the user stories are prioritized for implementation in iteration, they have enough information to be consumed by development team. This early user stories preparation leads to reduced cycle times and smaller queues for user stories’ unblocked tasks. It creates a pull system for user stories to seamlessly flow from start-to-end of an agile iteration without any impediments and delays.

This early preparation of user stories by ‘Product owner’ with the help of other stakeholders (marketing, support and anyone who can help in clarifying the needs and requirements related to user story) and the development team in getting the user stories ready or ‘Ready-Ready’(as they call it in scrum) for implementation.

This paper answers important questions related to getting ‘Ready-Ready for user stories’ before the start of the iteration.

Following questions are answered in this article:

What is ‘Definition of Ready’ (DOR) for a user story in agile iterations?
Why do we need to be ‘Ready-Ready for a user story’ before agile iterations?
How can we ensure that we are Ready-Ready for user story?
What is the advice to agile teams getting ‘Ready-Ready for user story’?

What is ‘Definition of Ready’ (DOR) for a user story in agile iterations?

‘Definition of Ready (DOR)’ is a ‘set of agreements’ for shared understanding of user story in a focused agile team. It signifies that the user story is ready, with all conditions satisfied, for implementation in upcoming iteration. User story should be actionable by agile team during the iteration, so that they can be consumed quickly for implementation. They should get Done-Done without impediments.

Why do we need to be ‘Ready-Ready for a user story’ before agile iterations?

Getting ‘Ready-Ready for user story’ has significant impacts on various aspects of iterative agile development (scrum sprints).

Following are some categorized impacts of getting ‘Ready-Ready for user story’.

1. Ready-Ready impacts on building (and discovering) knowledge and a shared-understanding of the user story in agile team for seamless (effortless) implementation in upcoming iteration.

The Product owner and the implementation team work at different cadences. Their focus, involvement and understanding of a user story are different at different times, i.e. before and during the iteration. Product owner may have more knowledge (not mandatory though) on the user story before the user story is prioritized for iteration, or at the beginning of the iteration. After the user story is part of iteration delivery plan, implementation team will develop more knowledge and understanding of user story, through continuous dialogues and discussions with the product owner. Irrespective of the differences in focus, involvement and understanding of user stories, all team members-product owner and development team, work together on a common goal of achieving a successful iteration and a successful product.

Time-boxed iterations (as in Scrum) are one way to synchronize Product owner and implementation teams different areas of focus; beginning of iteration is where the mental model synching can happen. If we have a set of user stories with clear ‘Definition of Ready’ or Ready-Ready state at the beginning of iteration, it serves as a synchronization point between Product owner and implementation team. It brings everyone on the common platform right at the start of iteration. ‘Well Begun Is Half Done’ – Aristotle.

Ready-Ready helps the team to focus on value-added discussions on the problem to be solved. It removes all unwanted, non-value adding activities around the user story discussions and elaborations.

Ready-Ready for user story helps in clarifying the basic acceptance criteria’s for the user story. Implementation teams will have solid foundations to conduct right contextual dialogues for elaboration of user story during the iteration.

2. Ready-Ready impacts on iteration flow.

Ready-Ready for user story helps in creating a flow in iteration. It helps in reducing the waiting queues at the start of implementation; it reduces the cycle time of user stories implementation; and creates a pull system where the user stories are quickly pulled, designed, developed, tested and delivered in a iteration., i.e. taking them from Ready-Ready to Done-Done state quickly. Also, since there is a good shared-understanding of the user story acceptance criteria’s, the design and development tasks related to the user stories can be organized in smaller batches to flow to the next stage (designàdevelopmentàtesting)of development. It enables continuous testing and feedback.

Ready-Ready for user story let’s everyone in the team know when a user story can be taken into sprint for implementation. It does not need to be “100% accurately defined”, and detailed out with all acceptance criteria; it should have enough details and initial cover-up discussions to get the development started.

Ready-Ready for user story reduces disruptions and waste caused by context-switching in agile teams— a lean iteration. Since the team are focused, they clearly know the right details of user story. The time spent in basic clarifications, evaluation, and unwanted experimentation is reduced. Note: User stories driven development still requires open conversation in team to succeed. Remember 3C of User stories – Card, Conversation, and Confirmation.

Ready-Ready for user story increases the velocity of the team. Since the user stories are already prepared for implementation, team can consume them quickly. It increases the team’s ability to complete more story points and hence increases their iteration velocity.

Ready-Ready for user story increases the probability of successful iteration (sprint). Team’s chances to deliver the committed items for the iteration increases. It will create wider acceptance of agile programs as the stakeholders will be able to see the results quickly—the working code.

3. Ready-Ready impacts on the quality of work done.

Ready-Ready for user story’ reduces the complexity of the user story. Ready-Ready requires story to be small enough to be completed in iteration. Small stories are less complex and better understood by implementation team. They can be implemented without any impediments with better quality.

Well groomed user stories encourage insightful dialogues, good discussions, more participations, clear acceptance criteria’s and shared-knowledge. All these, contribute to the quality of the iteration deliverable.

Ready-Ready for user story helps in minimizing the re-work, and maximizing creativity, and quality of deliverables.

4. Ready impacts on the agile team’s motivation and commitments.

Ready-Ready for user story increases the commitment and confidence of the team for accepted and committed work during the iteration. It eliminates all unknowns that hinder the right implementation of user stories; increasing the confidence level in the agile team. Of course, when we are clear on what has to be done, we show more confidence to complete it.

Ready-Ready for user story helps the ‘Product owner’ to gain confidence of the implementation team. She feels ‘involved’ right at the start of iteration which further helps in building an environment of open dialogues and conversation between team members.

Ready-Ready for user story will have impacts on the morale and motivation of the team. Team will have more control on the delivery of the committed work. It will increase the self-organization capabilities of the team; it will develop trust in stakeholders for the agile team; it will facilitate teamwork; and it will increase the collaboration between the implementation team and the product owner.

How can we ensure that we are Ready-Ready for user story?

Ready-Ready for user stories can be presented as guidelines or checklist for agile iterations. It depends on the team and how they want to incorporate it. Agile teams should remember that the Ready-Ready for user story is an evolving phenomenon. There is no fixed check-list which can be used. It will change based on the context of iteration. There will be some basic guidelines (checklist items) which will be common across all Ready-Ready user stories preparations.

They can be classified in following two 2 categories:

Common ‘Ready-Ready for user story’ guidelines and checklist: They will be common across all types of use stories
Context specific guidelines for ‘Ready-Ready for user story’: This will depend on the type of user stories we are developing in iteration. E.g. User stories around user interface development will have ‘UI mock-ups or wire frames’ in the Ready-ready list or required architecture guidelines and diagrams.
We discuss some Common ‘Ready-Ready for user story’ guidelines here.

Checklist for assessing the readiness for ‘Ready-Ready for user story’

(In no specific order)

No.	‘Ready-Ready for user stories’ check	Description	Are we doing it? Yes/No
1.	Is the user story well defined?	The Actor (Who is doing the action. ‘AS A’), The Action (work done, ‘I WANT’) and Purpose (value addition in performing the action, ‘SO THAT’) should be clearly conveyed in the user story. User story template – ‘‘AS A’ I WANT SO THAT ”.
2.	Do the user story follow the INVEST model?	The INVEST model for user story: Independent: The story stands alone with no dependencies. Negotiable: Story should act as a starting point of conversation during the iteration. This conversation between team members will result in details about the implemented functionality and the acceptance criteria. Valuable: It should demonstrate some well understood value to end customer. Estimable: Known story points for the user story to be completed within iteration. Small: A story should not take longer than a sprint to finish Testable: It should be easy to define and test the acceptance criteria’s.
3.	Are we confident about the value and intent of the user story? or Does everyone agree on the viability and usefulness of the user story?	Which means everyone agrees that user story is important for the product and should be immediately implemented to meet the product goals.
4.	Are all known basic user story acceptance criteria defined?	It does not need to be all acceptance criteria’s upfront. Most of them will be discovered when conversation on user story happens during the iteration. Basic expected behaviour of the user story should be clearly understood, and communicated.
5.	Are all dependencies of user story identified?	Tight coupling between the user stories make them difficult for prioritization and estimation. User stories can be split into two or smaller user stories or they can be combined together to be completed in single iteration to reduce the dependencies and its impacts on the readiness of the user story for iteration. e.g., Do we need to complete some other tasks before picking this user story? Do we need to wait for availability of some items (code, components, design etc.) from other teams? Have the dependencies among different user stories in the backlog sorted out? etc.
6.	Is the user story sized and estimable by team?	The early estimation of the user story is possible if we know the following: Do I have a realistic knowledge on how long it is going to take to build the user story? It won’t be right, but it needs to be a reasonable estimate given all that I know. Do we know at a fairly high level about the tasks to be done to complete the user story? Do we know the story points (measure for user story) required for the user story? Do we know our velocity (capacity and speed at which we can complete story points) for iteration? Do we need to merge or split the user story into more granular stories for better estimation? User story should be short enough to be implemented in single iteration. Otherwise it needs to be split into two or more user stories.
7.	Have we identified the owner; the person who will accept the user story after it is completed in iteration?	This has to be the product owner in most of the cases. Except for technical user stories owned by engineering team. e.g. Development of a product infrastructure component.
8.	Have we given some thoughts on how the user story will be implemented? or Do we need (or have) higher level solution design for the user story?	e.g. early UML class and sequence diagrams, or just white board sketches can help in knowing how the pieces work together.
9.	Have we identified all implementation impacts of user story?	1. Are there any critical design or architecture changes? 2. Are there any impacts on the implemented code? 3. Do we need any refactoring of existing code? 4. Are there any code flow change? If yes, do we know, how will we validate the code flow or any behavioural changes?
10.	Has the implementation team accepted the User Experience (UX) artefacts (if any)?	Basic Wireframes or UI mock-ups should be available.
11	Do we have good idea on what it will take to demo the user story?	Understanding of, what it will take to demonstrate a user story will give team an insight into the user story integration and deployment requirements. It can uncover unknown constraints for user story implementation and acceptance.
12	Has product owner committed and signed for the user story?	Product owner commitment is important for acceptance of user story.
13	Do we have our development environment ready for user story?	Any specific server, package, library etc. required?
14.	Do we know all the required non-functional requirements (Quality concerns: performance, scalability, availability testability, etc.) which will be affected by this user story?	Non-functional requirements (NFR) are cross cutting concerns spanning across multiple user stories implementations. User stories implementations should address these NFRs (or product quality concerns). The components created, and their implemented functionalities should positively enable required quality concerns. Create a matrix for NFR vs. components or classes created, modified and impacted by user story. Some early understanding of these NFRs, helps in reducing the design and development time of user story. It also helps in reducing any later re-work that is done to address these quality concerns. Build the NFR into the user story design and implementation.
15.	Can we implement this story in iteration? Do we need to break the story into two or more stories? Do we need to apply some constraints to the user story?	User story should be a single iteration consumable unit. Large user stories are complex and difficult to understand, debate, implement and test. Keep it small and manageable. User stories may have dependencies on other pending user stories, availability of external libraries or API’s etc. Knowledge of Non-functional requirements like performance, interoperability, robustness, availability etc. will also constrain and impact the readiness of the user story.
16	Are we making any assumptions related to user stories?	State all assumptions related to user story. Assumptions can arise due to solution boundaries or due to lack of information.
17	Do we have clear and shared-understanding of product and design principles and goals in context of user story?	Prioritized Product and Design principles will help the team on the following: 1) To help in making right design trade-off decisions. They serve as clear statements of what the team believe and agree on the purpose of product and design. 2) They help in setting right stage for constructive debate, and arguments within team about the user story. 3) They create visibility and clarity in decision making, and reasoning during the user story conversation. Product principles: Product principles guide the user story purpose. They are foundation for user story elaboration discussions; that take place in the team between developers and product owners. They bring together the product owner and implementation team on common platform. Product principles should be prioritized for clear understanding, and use in product decision making. E.g. What is more important for current release? – High usability or increased scalability to handle rapid user additions with acceptable and simple usability. Design principles: Design principles guide the design and architecture strategy. They help in making important design trade-offs. T Together, the clear and shared product and design principles can really ensure a smooth start of iteration. It will resolve design conflicts, help in design and implementation feasibility assessment, and quick user story acceptance and development. It helps in ensuring effective process for making early, informed, product and design decisions in iteration. e.g. Do we need to open our API’s for user access? This will depend on out product strategy, which, if yes, will influence the user story design and time lines. It is good to know these details in advance.
18	Are there any requirements for specific technical skills and knowledge?	External expertise like UI design experts, database expert etc.

What is the advice to agile teams getting ‘Ready-Ready for user story’?

Ready-Ready for user story’ definition will evolve. There are no specific template guidelines or checklist for ‘Ready-Ready for user story’. Depending on the context of the product, teams (skills, knowledge, involvement etc.), and type of user stories in iteration, these guidelines will evolve. Idea is to continuously brainstorm and retrospect during iteration, to create a dynamic, evolving list of ‘Ready-Ready user story’ guidelines. Include, what works, and makes the task of implementation of user story easy; exclude others non-value adding, squandering activities. The Ready-Ready checklist is a living document and should be kept up-to date with iteration feedback.

Getting ‘’Ready-Ready for user story’ is everyone’s responsibility. Though product owner is primarily responsible for getting the prioritized product-backlog user stories ready before iteration; it requires everyone’s involvements. At least, the key stake holders from the development team should be part of the process. Scrum Master, Business Analyst, team members, and anyone, who can be pulled to get the required user story details, should participate. Cross-functional agile teams should be responsible for creation, assessment, agreement and adherence to Ready-Ready.

Specific elements of ‘Ready-Ready for user story’ will likely be different for every team and project but there will be common elements across these scenarios. Once successfully implemented in one team, the concepts and knowledge acquired can be transferred and replicated to product iterations.

Iteration retrospection is a great source of feedback on ‘Ready-Ready for user story’. Ensure that Ready-Ready issues, and required improvements, are discussed during iteration retrospection meetings. Prepare to incorporate suggestions on Ready-Ready immediately in next iteration. Note: Ready-Ready creation is an evolving process.

Product owner should commit to Ready-ready. Product owners should take a lead in defining the Ready-Ready for user story criteria’s. Product owners’ full involvement and commitment is necessary for its success. Getting to the state of Ready-Ready for user story will require preparation from product owner before the user story is considered for iteration. Product owner should continuously refine, prune and groom the prioritized user stories in the product backlog before they become part of the iteration (sprint) backlog. Some upfront discussions before the start of iteration will ensure acceptance of desirability (what is needed?), viability (value addition), feasibility (implementation and experimentation) of user story for agile implementation team

Product owners should groom the epics and use stories in the product backlog in advance. Usually, having product grooming cycles half or one iteration in advance, before the user story is actually prioritized for the iteration is a good idea. Recent retrospections on Ready-Ready inputs are valuable and they can be incorporated quickly for Ready-Ready improvements. Doing it ‘too early’ or ‘too late’ will create issues. Doing it ‘too early’ will miss the retrospection inputs. Doing it ‘too late’, will not leave enough time with the team to uncover and unblock the unknown risks associated with the user story. It will still require some upfront planning from the implementation team to discuss (with product owner), and get the user story in Ready-Ready state.

Only Ready-Ready user stories should be scheduled for iterations. Scrum master should ensure that only Ready-Ready user stories are scheduled for implementation in iteration.

Getting Ready-Ready for user story should be a planned activity. Scrum master should dedicate time during iteration to participate in grooming exercise for getting the prioritized user stories Ready-Ready for next iteration. As discussed, the goal of preparing the user stories for the next sprint and allocating time for it will increase the overall flow during future iterations.

MindMap files

1) FreeMind mind map files(..mm format) are available for download. ->Click here.

2) Click the image below to get the jpeg for mind map(best viewed in Chrome browser with zoom).

Ready-Ready for user story

Design Trends For 2013

Gannon Burgett have a assembled a list of 13 Design trends for web and native applications user interface we will see in 2013 – 13 Design Trends For 2013

Following is the list of design trends to be seen in 2013

1) Flat design : 2 dimensional grids
2) More use of Gestures in mobile interface:
3) Affordable animation
4) Wider websites, Larger fonts
5) Responsive web design
6) Native Apps
7) GIFs as design elements
8) Wider bigger Search inputs
9) Human centered design
10) Vector – Sketch

Nunav- An intelligent traffic navigation system from Graphmasters

Graphmasters(formely Greenway) have come out with an intelligent traffic navigation system called Nunav.
The system orchestrates the traffic through a distributed routing algorithm in an optimal way.
Checkout the video of Nunav product at the company’s website
Interesting to see how new innovations are driving our cities to go green. Future of green cities.

Behavior Driven Development

What is Behavior Driven Development(BDD)?

If you have practiced Test Driven Development (TDD) is that BDD drives its value from principles of TDD (which focus on incremental design delivery) where the Software development team(Product owner, Business Analyst, Development and Testers) incrementally create common and shared understanding of the next most valuable behavior to build in the system to realize the best incremental value.

This required behavior is captured as specification in Acceptance tests and its scenarios and developed incrementally using BDD with focus on Behavior of the System under envelopment not its implementation details.

BDD concepts and practices are promoted by Dan North, who realized the during his TDD training classes that TDD is too Test focused and has probkem. In his words –
“I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails”

Definition from Dan North, the creater of the BDD approach is as follows:
BDD Descroption from Dan North during

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

Simple Introduction
Let’s make it simple for everyone to understand. Let’s try to understand the follow question:

Assuming What happens between team members (Product owner, Developer , Test engineer) developing a User Story?

–

BDD Practice

BDD is customer driven where customer describe the behavior of the application feature in natural language with the help of examples. Examples are elaborated using the GIVEN-WHEN-THEN scenario description techniques, which means GIVEN an initial context, WHEN the event occur, THEN the application should exercise the behavior.

These examples are automated and converted to Acceptance tests.

Acceptance tests methods emphasize use of ‘should’ and ‘ensure’ keywords for describing the behavior of software to help clarify responsibility.

Example: For feature acceptance test

Scenario: Inventory should be checked for each item before confirming an order

Given a customer has filled the shopping cart with an order of multiple items
and the inventory store is available for access
when he activates the request for the order placement
then all items in the order should be verified for availability in the inventory

public class OrderVerificationTest{
 
   @Test
   public void shouldEnsureThatOrderItemsAreAvailableInInventory() {
      Inventory invnt= MOCK(Inventory.class);

      Order order = new Order();

      order.addItem("item1");

      order.addItem("item2");

order.placeOrder(); //check if the invnt.checkAvailability(item) is called twice,once for each item in the order when placeOrder() is called; }}

What is the advantage?

Collaboration: BDD brings all customers (or PO, BA representations ) together in describing the behavior of the system.

Ease of implementation change: The behavior of the system under design and implemenation hardly chnages. Its the implmentation of the system behavior that can chnage. If the Behavior chareteristics are static, why not have them abstracted out in a structure which is independent of how the final implemnattion. This is great advantage of BDD. Think and

Ubiquitous language for stake holders:

Ease oif Refactoring:

Process of BDD:

Tools for BDD

1) Fitnesse
2) Twist
3) JBehave
4) Cucumber for Ruby
5) Rspec for Ruby
6) Specflow for .NET
7) CBehave: A Behavior Driven Development Framework for C

Language for BDD:

Given:
When:
Then:

Following are some good links on BDD:

1) Introducing BDD by Dan North.
2) BDD is Like TDD by Dan North.
3) Short description of BDD – BDD in Nutshell by Rachel Davies
4) Wikipedia page on BDD.
5) Liz Keogh’s blog on BDD
6) IBM article. Very good example driven introduction of BDD – In pursuit of code quality: Adventures in behavior-driven development
7) BDD approach to defining and identifying stories – Whats in a story?
8) Good stackoverflow discussion
9) Another small example for JBehave BDD users by Giordano Scalzo’s Personal Blog
10) Good Presentation slides on BDD and JBehave by Nikolay Vasilev.
11)

Scott Ambler on Agile Architecture

I have been doing some research on agile architectures. I am also writing an article on the same. I recommend the following article from Scott Ambler for everyone trying understand the architecture creation and evolution in agile world.

Agile Architecture: Strategies for Scaling Agile Development