agile assessment report - agilefaqs - expert agile, scrum ...€¦ · summary of our visit ......

Copyright © 2013, AgileFAQs. All Rights Reserved.

Agile Readiness Assessment Report

Dec 17-21 2012Naresh Jain

[email protected] @nashjain

http://nareshjain.com

mailto:[email protected]


http://exortech.com/blog



This report contains...

Expectations of our visit

Summary of our visit

Our current understanding of the overall teams & processes followed

Summary of discussions with various groups within the Org.

Observations: What we found

Conclusion and Recommendations

Plan for the next 12 months


Expectations from the visit

Understand current state of the organization in terms of process maturity & cultural compatibility with Agile

Formulate a strategy (plan) to improve team’s effectiveness and to take the teams to the next level

Figure out a way to make the Agile DNA an integral part of the company’s internal improvement initiative


We had to understand...

Current state of affairs and how the teams operate

Key challenges faced by the team and its management

Key stakeholders and their expectations

Gaps in terms of knowledge and skill levels of the team

Historic data to understand the performance of the team


Deliverables of this Assessment

Agile Adoption Roadmap (with specific recommendations for training/coaching)

Identify Potential Internal Coaches

Risks Backlog

Specific feedback to teams who were interviewed during the assessment

Basic Agile overview


Summary of our visit


What was done

Discussion with four teams to understand how they operate as of today

Process, Team composition, etc.

Current Org. structure

Value Stream mapping of their development process

To identify bottlenecks and gaps

Interviews and Reviews

To understand current pain points

Watching standup meetings

Observe team’s behavior


Rationale Behind Agile Overview presentation

Meeting with important stakeholders to understand their expectations and pain points

Pairing with Developers

Technical Debt, Code Quality, CI and other infrastructure

Pairing with the Testers

Test plans, Test cases, building Quality into the Process

Discussions with Scrum Masters and Project Managers

Planning, Estimation, Velocity, Retrospectives, etc.

Discussions with the Business Analysts

User Stories, Product Backlog, Acceptance Criteria, Reviews

What was done...


Time Meeting ParticipantsDay 1

09:00 AM - 10:00 AM Overview of teams, their structure & responsibilities, Organizational Background General Manager, Quality Head, VP of Engineering

10:00 AM - 11:00 AM Insights from the Quality Team Quality Head, Couple of Quality Leads

11:00 AM - 02:00 PM Overview of the First Project by their Project Manager and Product Owner Project Manager, Product Owner, Scrum Master

2:30 PM - 7:00 PM Detailed review of Project 1 Entire Team (Devs, QAs, BAs)

08:00 PM - 9:00 PM Discussion with CTO Office CTO, Lead Architects

Day 2

9:00 AM - 10:00 AM Day 1 retro General Manager, Quality Head, VP of Engineering

10:00 AM - 11:30 AM Insights from key Project Manager and Product Owners regarding their current challenges around existing processes Product Managers, Product Owners

11:30 AM - 02:30 PM Overview of the second Project by their Project Manager, Scrum Master and Architect Project Manager, Architect and Scrum Master

2:30 AM - 6:30 PM Detailed code review of Project 2 Entire Team (Devs, QAs, BAs)

Day 3


10:00 AM - 11:00 AM Insights from the ScrumMasters. Discussion around challenges faced by the SMs Scrum Masters across different projects

11:00 AM - 12:00 PM Executive Management meeting Executive Management

12:00 PM - 05:30 PM Overview of Project 4 by PM & SM. Followed by detailed project review PM, SM

05:30 PM - 06:30 PM Discussion with Automation Tester from Project 1 Automation Tester

Day 4


10:00 AM - 01:00 PM Agile Way of Dealing with Uncertainty in a Complex Adaptive World - Workshop Key representatives from different Projects

2:00 PM - 3:00 PM Review with Design Team on how agile’s evolutionary design fits into the company’s design process Architects from Design Team

3:00 PM - 4:00 PM Review with Analyst Team on how requirements are gathered and managed on Agile projects Analysts from Requirements Team

4:00 PM - 5:00 PM Review with Architect from CTO office to understand how they are executing projects Architects from CTO Office

5:00 PM - 6:00 PM Discussion with Project 1’s Architect Architect

6:00 PM - 6:30 PM Discussion with Project 3’s lead tester Lead Tester

7:00 PM - 8:00 PM Insights from Business Development/Sales Team to understand what customer’s are asking for & how, Agile will help them Sales and Pre-Sales Team

8:30 PM - 9:30 PM Meeting with Practice Group owners to understand how Agile will impact (help) them Practice Group Owners

Day 5

09:00 AM - 10:00 AM Day 4 retro & plan for the day General Manager, Quality Head, VP of Engineering

10:00 AM - 01:00 PM Feedback to individual teams PM and SMs from the 4 teams

01:30 PM - 06:00 PM Working on the roadmap General Manager, Quality Head, VP of Engineering

Agenda


Our Understanding So Far...


Org Structure

Image faded out for privacy concerns


Challenges faced by PMs/GPMsHow to motivate individuals to try Agile? How to help them understand that it actually helps

How to educate/expose the teams to Agile

Changing people's mind set

Push back on daily tracking

How to educate customers so they don't take advantage of Agile in the wrong ways?

How do we Institutionalize Agile?

What is the standard Agile process with best practices?

Does Agile work with Jr. Devs?

How to build trust/faith factor in small projects?


Challenges faced by PMs/GPMs...Agile Testing

Testing in pieces - bugs slip through & quality is compromised

What kind of testing is required/possible in 2 weeks sprint?

In a 5-day sprint where does QA cycle fit?

QA does not have enough time in the sprint to complete testing

What tools to use? - TFS, Testing?

How to set up Information radiators - task boards, burn down,...?

How to manage risk inside Agile?

Changing implicit behaviors

Not thinking through end-to-end scenarios

No documentation/specs - where to draw the line?


Challenges faced by PMs/GPMs...How to freeze requirement before the next sprint (esp. for distributed teams)

How to manage clarification and expanding scope inside the sprint?

How to lock down the scope?

3-4 months Fixed price projects & Agile? - CRs or not?

Agile Planning

How to do Estimations in Agile?

How to avoid burn outs?

How to provide better & more reliable Visibility/Projections?

Productivity

How to improve Velocity?

How to measure and show productivity improvements?

What are the quality and productivity metrics?


Challenges faced by Certified ScrumMastersNeed a better way to handle planned and unplanned releases

On a past project, working with Distributed Teams .i.e. team members belong to different companies - it was very difficult to get visibility/updates from them

Convincing customers to implement Scrum in the proper way

Management Awareness - mix up of roles (PM, SM)

Teams still waiting for direction from PM/SM

Education Gap

Very few stories are picked up by the team

They don't like changes in plan

Automation vs. manual testing

Questions around QA process in scrum

Lack of requirement clarity

Metrics?

How to deal with sprint spillovers?


CSM - Advantages of Scrum

Get to see something early

Early time to market - don't have to wait for everything to be completed

Collaboration

Changes can be incorporated - pleases the customer

Higher feature ownership

Continuous Integration

There are good points, but some core benefits were left out.


CSM - Limitations of Scrum

Need teams members who can independently execute items

Leads to sub-optimal resource utilization

Velocity fluctuation

In fixed bid projects - both the team and the customer satisfaction is low

I’m sorry, but I don’t think they really understand Scrum or AgileClearly they need more experience before claiming to be a Scrum Master.


Project 1


Project 1’sTeam Structure


Project 1’s Release Process

1-2 Weeks

Pre-Release Release

3-4 Months

1. High-level Estimates

2. Impact Analysis

Release Planning

5-10 Days

1. Detailed Estimates2. Task Breakdown3. Task Assignment4. Detailed Design5. Test Plans6. Enter tasks in TFS7. Project Plan in MS

Project8. Agreement from

customer

3 Weeks 4 Weeks 2 Weeks 3 Weeks 1 Week 16 Hrs

Milestone 1 Milestone 2 Milestone 3 Integration TestingIn QA

Regression TestingIn Staging

Deploy

LiveDevelopers

1. Low-level Design2. Coding3. Unit Testing4. Code Review5. Launch Plan

Testers1. Test Cases2. Buddy Testing

Developers1. Fix bugs from M12. Low-level Design3. Coding4. Unit Testing5. Code Review6. Launch Plan

Testers1. Deploy2. Update Automation IDs3. Manual System Tests4. Buddy Testing5. Create new Test cases6. New Automation tests

Same thing...

Code Freeze

Developers (next release)1. High-level Estimates2. Impact Analysis

Testers1. M3 testing2. Regression testing

of M1 & M2

1. Ops execute the Launch plan

2. Regression testing

Biz Sign-off


Good Initiatives on the Project

Buddy testing

Score card - self rating + customer voting

Constantly trying to reduce the testing cycle

Continuous improvement - tracking test cases in TFS, trying to automate manual tests

Trying to improve communication/transparency with Weekly, Monthly and Quarterly review report


Management Challenges Highlighted by the Team

16 hrs Deployment process is very stressful

Release Planning is long and stressful. Yet the predictability is poor.

Knowledge Islands

Resource Dependency (work allocation) - Certain people are good in certain areas and only they keep working on it due to the pressure

Attrition - when an experienced developer leaves it take time to replace him/her. Ramp up time at least 1 month

Estimation & planning is not effective as there is constant crunch time

Lot of pressure from client-side and that pressure is passed on to the team

Multiple things are running in parallel & too much of context-switch, reducing efficiency


Customer Needs Related Challenges Highlighted by the Team...

Backlog Prioritization is difficult

Overall team's efficiency has been questioned by the customer. Customer keeps asking - "how do I know this is optimal productivity?"

Breaking down backlog items is hard

3-4 months release cycle

Lot of change requests come during the 3 month release (25 CRs in last release, 40 CRs before that)

SLA does not allow for rotating people


Technical Challenges Highlighted by the Team...

Environments have different configuration (Staging, Dev, QA, Prod)

Software on the trunk is not always in a releasable state - 2 Weeks of integration testing

Developers can't build the whole solution on their machine

Impact analysis is difficult. Even though TFS has an impact field, it really does not help


Quality Control Challenges Highlighted by the Team...

300-400 Defects each release

Right Devs vs. QA ratio?

Constantly time crunched, which leads to not really following the test cases. Doing more of a high-level scenario testing

Automation: Many things are not possible or don't know how to do. So its not really paying off the investment

Many Environmental issues while testing (due to shared QA Env)

Not able to do any Load Testing

Tools: PMs are using a mix of tools from TFS, to MS Project Plan to Excel


My ObservationsTeam is getting burnt out. I also see some serious capability issues with few members. If you see the overall quality of design, code & tests, it getting worse day-by-day.

Splitting team into support/maintenance & new feature teams is a classic anti-pattern.

Attended their estimation meeting - due to knowledge islands, no one knew the complete picture. There were quite a few new scenarios getting discussed which was not recorded anywhere. Also a lot of guess work was going on in estimation process. Some people weren't speaking. Testers were missing. Overall meeting effectiveness was low.

Team lacks collective ownership. Devs take more time & testers are getting squeezed.

There is no single person who understands the whole system & has the big picture including all the historical decisions.

Trivial changes are considered as change requests. Team feels that they are very stressed and bothered about the changes coming in.

Misconception among people on Agile.

Team feels that Scrum is bad. However, when poked further they are confused on the benefit of scrum vs. current model.


My Observations...Estimation is done in hours/days

Poor code quality

Average file is 700 to 2500 lines of code.

Conditional logic is deep and hard to understand.

Unit test is written for name sake and doesn't even verify anything.

People aren't even aware that this is bad.

Team is not aware of their technical debt. No idea of current code coverage.

Quality of developer tests is very poor

So called unit tests are really service/behavioral tests.

Tests are really huge with lots of conditional logic. Tests are really hard to understand.

Most tests don't have any assert statements.

Tests are not part of CI build. Rarely developers run them or update them.


My Observations...On an average there are 200 - 300 bugs for a release. This is very high for a 3 month release. Many bugs are straight forward happy path tests.

There are knowledge islands in the team. When there are touch points between modules/features, things start breaking.

Reduction of test cycle has squeezed things further.

70-80 hours is taken away to depend on automation. However, testers feel that automation is not helping them.

This team is using their own version of a keyword driven automation tool on top of selenium. Generally keyword-driven automation tool is not recommended. Defeats the purpose of creating Selenium.

Massive duplication in manual test cases which are not updated whenever there is a change.

CI server doesn't check for items like code coverage, coding standards, cyclomatic complexity, traceability and similar aspects.

Team members waste too much time on branching & merging. Its an anti-pattern.

TFS is not used effectively by everyone - Product & functional owners don't use TFS.


My RecommendationsMove from the big 3-4 month release cycle to 2 week Sprints.

Practice pair-programming to resolve the knowledge island issue.

Invest heavily on scripted automated tests using Selenium.

Explain the rationale behind the process to the team & get their buy-in.

Integrate the automated tests into the build & run it with every checkin on the CI server.

Add static & dynamic code analyzers to the build.

Practice Behavior Driven Development to improve collaboration.

Focus heavily on design improvements, code quality and code hygiene.

Invest in productivity tools like ReSharper & a better code review tool.

Developers should improve their unit test coverage significantly.


Project 2 Team


Project 2 Team Structure


2 Week Sprint Cycles

M T W T F

M T W T FTech Discussion (30 mins)

Sprint Review 1-1.5 Hr

Standup -30 minsRetro 1 hrSprint Planning 1-1.5 hrs

Client Meeting 1-1.5 hrs

Standup -30 mins Standup -30 mins Standup -30 mins

Standup -30 mins Standup -30 mins Standup -30 mins Standup -30 mins

Tech Discussion (30 mins) Tech Discussion (30 mins)

Code Freeze

4 Hrs Capacity 7 Hrs Capacity 7 Hrs Capacity 7 Hrs Capacity 7 Hrs Capacity

6 Hrs Capacity7 Hrs Capacity7 Hrs Capacity7 Hrs Capacity7 Hrs Capacity


Interesting things on the projectGiven the performance improvement nature of the project, the overall approach taken to slice payroll portion, migrate it to the new architecture and testing it out first, is a great example of tracer-bullet approach.

Customer come down to Bangalore to kick-off the project. This helped them understand the culture & bond with the team very well.

The process is fairly streamlined using Scrum.

Testers have automated all the manual tests to perform regression and load tests:

Regression: Data-restore, updating the server config, resetting IIS, running MSTests and finally reporting the time taken & number of payrolls processed

Performance: SQL script to load the payroll info in the db, trigger the payroll processing and finally retrieve (collating) the timing information from database


Challenges highlighted by the TeamClient has their own TFS and does not allow the team to customize it. Team ends up using internal TFS for managing sprint execution. Due to data being distributed in both TFS there are challenges to produce burn-down, capture efforts, root cause field, etc.

Team is not practicing certain practice like backlog grooming, retrospectives and planning poker. GPM is concerned that they are not following pure Scrum.

Since the nature of the project is performance optimization, there are many items which require investigation. These stories are hard to estimate and leads to complications in the sprint commitment.

Developers are spilling over the code freeze, eating into testing time

Due to client’s mandate, team is using multiple disconnected tools like TFS, Perforce & MTM. This leads to traceability being an issue.


Challenges highlighted by the Team

The Daily Scrum meetings are running over 30 mins

Customer feedback is that the team is very shy & not really asking questions

People easily get into the silos, disrupting team collaboration

Procurement of 3 servers took more time than expected, so could not test on ideal environment

Sharing these servers for both Dev and testing env, causing issues

Mid way thru performance testing, new changes are constantly pushed, disrupting testing


My Observations

Considering the nature of the project, Scrum is not the right model. Kanban is a better approach as the work is hard to estimate (hard to say what would fit into the 2 weeks sprints)

PM and GPM understands the process well. However the team does not understand the process nor the rationale behind it.

Tester are manually running tests which could be easily automated 100%. These can be integrated with the build and run automatically.

Testers are not writing many new tests. Mostly reusing tests given by customer, which are very high level. They cannot be relied upon 100%. There are many other areas which they should ideally test.

Tester-developer collaboration can be significantly improved.

Teams are not using productivity tools like ReSharper.


My Observations...Poor code quality.

Average lines per class is 500.

Classes are filled with getters/setters.

Design is not Object Oriented.

High complexity (too many if/switch loops)

Local instance of CC.Net is set up for continuous builds. But FXCop, StyleCop, Code Coverage are not set up on internal server. Its only there on client side. Team members have to manually run these tools on a different machine.

Team members don't know what their current code coverage is. They mentioned that the on-site person knows about it

Stories are not written effectively.

As a developer I want to use IOC container to refactor the payroll queue logic

As a product owner I want to perform report of the payroll process so that I can compare with the baseline to understand performance gains - 5K+1server, 5K+3Server,10K+3Servers.....


My RecommendationsSwitch to Kanban from Scrum. It will help:Address the estimation problem due to the nature of the work.

Will help the team focus on single-piece flow, hence higher throughput from the customer’s point of view.

Reduce the Scrum process overheads to a large extent.


Integrate the automated tests into the build & run it with every checkin on the CI server.

Add static & dynamic code analyzers to the build.



Developers should improve their unit test coverage significantly.


Project 3 Team


Team Structure

App Design

ASPXBiz Layer

+Entities

DAODBADO.Net

Stored Procs


2 Week Sprint CyclesM T W T F

M T W T F

M T W T F

Demo 1-1.5 Hr

Standup - 60 minsDaily 8-9 PM

Offshore Retro 30 mins

Sprint Planning 1-1.5 hrs

Client Retro 1 hrTech Discussion (30-60 mins)

Code Freeze



PreviousSprint

CurrentSprint

Standup - 60 mins Standup - 60 mins Standup - 60 mins

Standup - 60 mins Standup - 60 mins Standup - 60 mins Standup - 60 mins

Tech Discussion (30-60 mins)




Development

Development Sprint Testing UAT (BA) Regression Testing

Standup - 60 mins

EstimationsUser Story AuthoringAcceptance Criteria

Low Level Stories + Tasks





High Level Stories

High Level Stories

High Level Stories

High Level Stories

High Level Stories


Testing Cycle during ReleaseM T W T F

M T W T F

M T W T F

Code Freeze

Development

Release

Dev Integration Testing QA Integration Testing Staging Integration

Testing

Staging Integration

Testing

Min 6-7 Days of Manual Testing before every Release


Challenges highlighted by the TeamNew requirements/CRs during sprint

80-90% sprint items are finalized by Thursday (2 days before the sprint), but remaining items (10-20%) can change after the planning

Rework for testers due to mid-sprint CRs

BA does not get enough time with the PO to get/clarify requirements

Retrospective

Retrospective action items might get dropped out. No action items from retros - ownership & analysis?

Retros are not taking place for the last 3 sprints (due to release pressure)

Too much pressure of release

Closer to release, QA are under heavy time pressure as they need to perform regression and sprint testing

Team is working 10-12 hours per day

Customer thinks the team is buffering their estimates and wants productivity improvement measures

Estimation (Story point to hour conversion)


My Observations - User NeedsUser stories are very granular. Defeats the purpose of having user stories

Change management process is too tedious as developers & testers are expecting everything to be added as a story with screen-shots. This adds significant overheads. This can give the impression of poor productivity to customer

Lot of productivity wasted in detailing out requirements and dealing with smaller changes as CR

Acceptance Criteria are really scenarios, which could be written in-terms of BDD tests to improve effectiveness

PO is involved in daily stand-ups, but not really signing off on the stories as and when they are ready for review

No story maps or tree structure for the User Stories - makes it hard to do impact analysis

Team does not seem to understand customer needs very well. They expect the BA to take care of everything and babysit them from the requirements point of view


My Observation - Team & ProcessTeam & Customer doesn't seem to understand the process and they haven't bought into it.

Team bonding/ownership was found lacking. More of individualistic approach. There is a significant productivity issue due to this.

Stand-up meetings are essentially a status meeting (micro-management)

Scrum Master is on-site and the team is here. Does not make any sense

No information radiators in the team area

Team is spending a significant amount of time in meetings (late night)

There is lot of work required to get to a decent Agile model. Team is currently doing mini waterfalls.

Currently not a very systemic way of estimating. There are misconceptions among the team about the estimate for individual stories. There is a big gap in estimation. Team is internally mapping 1 Story point to 2 hours. Defeats the purpose.

Massive productivity issue that needs to be resolved.

Consider moving to Kanban model instead of Scrum.


My Observations - Tooling

Team don't understand how to effectively use Jira to manage their backlog.

Burn down and other reports are not available for team review.

Team has Jenkins and Hudson CI server, but its been used mostly for continuous builds. No static code analyzer or any other tools to keep track of things like code quality, code coverage, etc.

Devs use visual studio. They don't use any productivity tools like ReSharper on top of it

Branching (Feedback & Flashcard branches) and merging - seems like the default way to work. Big anti-pattern


My Observations - TechnicalTeam inherited a lot of old (poor) code. After clearing up the code they demonstrated it to the customer. However the code quality is rapidly going down. Complex, monolithic design. No proper unit test. Tests are not run by developers with every change.

Inline SQL statements are converted to Stored Procedures in the name of performance improvement. This is a bad idea, since scaling database is really hard. Also application will get tightly coupled with the database since stored procedures are db specific & hard to port. Stored procedures are also hard to unit test.

Developers lack basic coding practices like externalizing labels/UI text to enable easy modification which can help reduce changes and improve productivity.

Long checkin cycles (one checkin per user story.)

Testers are not doing any automation at all. Selenium IDE could be used to automate even if testers don't know automation.

Lack of end-to-end traceability in the project.

Testers don’t understand the difference between +ve & -ve path testing.

3 stories have the exact same acceptance criteria & the tests are simply duplicated


My RecommendationsSwitch to Kanban from Mini-waterfalls.

Seriously need to review the capability of certain team members. Developers and testers need a lot of spoon feeding in terms of extremely detailed out specs with screen shots of things like tooltip, etc.


Planning and Estimation needs an immediate attention.

Cut down all the useless (name-sake) meetings

Considering that there are total 8 screens in the app, invest 2-3 days to create a suite of automated selenium tests.

Integrate the automated tests into the build & run it with every checkin on the CI server. Add static & dynamic code analyzers to the build.



Developers need to write automated unit test & improve coverage significantly.


Project 4 Team


Team Structure

On-site (UK)Offshore (India)

Scrum Master

Lead Dev 2 Devs

BAProduct Owner


2 Week Sprint Cycles

M T W T F

M T W T FRelease

Sprint Review 1-1.5 Hr

Standup -30 minsRetro 1 hrSprint Planning 1-1.5 hrs

Standup -30 mins Standup -30 mins Standup -30 mins

Standup -30 mins Standup -30 mins Standup -30 mins Standup -30 mins

Release

Change requestBoard approval




Things working well according to the Team

High predictability (97% SLA targets achieved)

Compared to other teams, this team is fairly streamlined

On-site BA is able to chase business to get things done

Because of the transparency & visibility in Scrum, the business is able to pressurize the change control board to approve the releases faster

BA is able to do the testing and give rapid feedback to the developers


Needs Improvement according to the Team

Release process is slightly heavy-weight due to the change control board & it can become a bottleneck

Sometimes mid-sprint there are high-priority change coming in from the Sr. Management

Due to client restrictions: the team has to use TFS for some stuff, time sheets are in a different place, bugs are in QC, client requirements are in Google Docs and some more stuff is managed in XLS


My Observations

Considering the following aspects, I believe Scrum is not the right model for this team. Kanban might be a better fit.

nature of the work - mostly adding/updating reports, tweaking cube logic, ETL changes

no separate build or regression testing process

the release cycles are independent of 2 week-sprint cycles

good churn mid-sprint

Having burn down charts and other information radiators could help the team

Team is using the typical user stories format, but its quite repetitive & does not seem to add value (As a product owner I want to...)


My Recommendations

Switch to the Kanban model (reasons highlighted on previous slide)

Do away with ceremonies from Scrum that are not really adding value

BI team has a total of 4 sub-teams called Quality Circles. One of them has moved to Scrum, while others are using a traditional iterative process. Now that one team has successfully moved to Scrum, it would be a good idea to follow the same process on all the sub-teams.


Org. Level Observations

What we found.

Copyright © 2005-12, AgileFAQs. All Rights Reserved.


My Observations

Even though teams are reluctant to change, we can get them excited to try and learn new ideas.

Throughout the organization, there is a very early, but growing culture of openness, communication and transparency.

The sense of team commitment is lacking, team members are reluctant to jump in and help each other.

The teams are really stretching to make their customers happy.

Collaboration within the teams needs massive improvement. Teams are not self-contained.

There are varying levels of maturity along the agile journey amongst the teams.

Teams are picking up the practices, but I would like to see them critically think about the values behind those practices and figure out variations or adaptations to those practices to better suit their environment without sacrificing the value.


My Observations...

Misconceptions about Agile: Overall the teams aren’t excited about Agile, they need a lot of help to make the transition. There are quite a few misconceptions about Agile that need to be cleared.

Management Commitment: There is a strong backing from the management to improve the current state of software development.

Domain Knowledge: System domain is fairly well understood by the team, however business domains and value propositions need more understanding.

Churn and volatility: Teams agree on sprint Goals, but during the sprint there is a good 40-50% churn.

Mini-Waterfall: At a very high-level, the overall process followed seems like mini-waterfall process.

Every team seems to complain about extensive customer pressure.


My Observations...Team lacks skills: Most team members lack necessary skills to be successful in an agile environment. They will certainly need a local coach/mentor to help them.

Need help with Agile: Based on my interactions with the team, they need help to understand Scrum/Kanban framework, relative complexity estimates, planning, stories, collaboration, etc.

Lack Technical Skills: Developers and Testers need specific help with eXtreme Programming skills and practices.

Old-school Testing Practices: Overall testing practice still seems to be in the “inspection” model, rather than building “quality-in” model

Distributed Development Challenges: Distributed nature of depended teams is causing quite a few challenges. Strong coaching is required to ease some of the problems.


Agile Skills Lacking in the teams

Embracing uncertainty/change and effective finding ways to deal with it

Tight collaboration and Communication with everyone involved

Teams are predominantly baby-seated by Seniors on the team

Eliminating Waste

Collective Ownership, Drive (self-motivated), Focus and Discipline

Fail-fast: Breaking a large problem down into small safe-fail experiments and then willing to try and learn quickly.

Systems thinking

Critical thinking

Open to experimenting with radical ideas


Misconceptions

Roles of PO, SM, PM, TechLead, Tester

Estimation, Velocity and Capacity

Why Agile?

Self-Organizing Teams

Clean-code

User Stories and Acceptance Criteria

Basic Scrum ceremonies


Reasons for Churn during the Sprint

Customers change priority (mostly for valid reasons)

Teams lack good understand of the customer’s needs. They are very driven by requirement specs, which can’t capture their changing needs

Lack of collaboration between the teams, the Architects and other stakeholders (customers, onsite coordinators)

Testing & integration done late in the cycle causing sprints to overflow

Most teams lack experienced team members to guide the team

In some critical areas, poor implementation is leading to more churn

Most teams have knowledge islands which creates heavy inter-dependencies between them and multiplies the churn introduced by the above points


RisksOverall the company is not ready for Agile (rapidly inspect & adapt.) Yet, that is the need of the hour to grow & sustain the business.

The product discovery & estimation process at the beginning of the sales process is not aligned with the Agile model. I feel many projects are set up for failure due to this process.

Teams seem to be pushing back on small CRs instead of truly collaborating with them & moving up the value chain & win their trust.

While the company is trying to grow rapidly, the foundation is not in place for this growth. Quality of many team members is questionable. I see a huge amount of inefficiencies in the teams.

Talking to the Sr. Management, I feel they are very strong, right vision & focus, but they don’t seem to have a matching team that can deliver as per their & their customer’s expectations.

The Management still relies on classic inspection (random sampling) based SQA approach, which cannot change people’s behavior, rather forces them to game the system (plus all the overheads).

Also this model does not scale. You need a model which is built on distributed cognition.

The L&D team is doing a great job, however they have a long way to go. The company lacks an informal learning culture. Teams are fairly out-dated on technology, tooling, techniques, etc.

While the CompanyName way is a great initiative, its very focused on documenting how things are done currently. Instead they should be focused on making a quantum leap. The industry is moving beyond Agile.


Recommendations


Developers need help with the following topics

Good Design Practices

Understanding and improving code quality

Understanding the bigger picture and asking for it

Working effectively with Legacy Code

Test Driven Development & Behavior Driven Development

Working effectively in a distributed environment

Evolutionary Database Design and Refactoring Databases

Thin Slicing and Evolutionary + Incremental Design/Implementation

XP Practices like Continuous Integration (to avoid branching), Pair Programming, etc.

Better productivity tools like ReSharper

Fail Fast approach

Knowledge Sharing

Impact Analysis

Effective unit testing


Tester need help with the following topics

Work more closely with the Team daily to build quality in (prevent defects from getting in the first place rather than inspecting at the end)

Collaborating with Product Owners, BAs and Devs to build domain & tech knowledge

Collaborating with the PO/BA to better define User Stories and Acceptance Criteria

Work with Devs to practice Acceptance Test Driven Development

Exploratory testing and mistake proofing.

Create and maintain an effective automated (scripted) test suite


BA need help with the following topics

Communicating the Product Vision and Roadmap (at least feature level)

Story mapping and product discovery

Understanding the business drivers, priorities and value chain

Writing effective user stories

Slicing stories functionally rather than technically

Defining better Acceptance Criteria for the stories

Helping the teams independently make implementation decisions

Risk identification and mitigation for each story

Collaboration with other team members to work-out dependencies

Facilitating better knowledge sharing with the team


ScrumMaster/PMs need help with the following topics

Understand the essence/spirit of Agile

Using techniques like Value Stream Maps to identify bottlenecks

Create Self-Organized Empowered Team

Emerge as leaders and be the voice of the team, shielding the team from external interferences

Facilitating more effective meeting (Planning Meeting, Standups, Demos)

Capacity Planning

Story Point (Relative Complexity) Estimation

Intent behind standup meeting

Using Retrospectives as a means to continuous improvement

Process to following up on Retrospective action items


Potential Internal Coaches

We’ve identified a few people who can be mentored to be good Agile Coach. Details about these folks were already communicated.


Plan


The Million Dollar Idea

Agile Working Group

Pilot ProjectsTypical Cloud Project

New Custom Software Delivery Project

Internal Project

Ongoing Maintenance Project

2-6 months

Agile & Org. Transformation

Experts

Coaching

Mentoring

Learn

Try/Apply

Refine & Standardize

SQA,Internal Coaches

&Practice Groups

All ProjectsCoach, Mentor, Support & Learn

USE

REFINE

INTERNA L

COACHES


High-Level Improvement Areas (Focus Areas)Agile DNA

Culture to embraces change

Innovation centricity

Team collaboration

Team events

Awareness

Transparency

Customer collaboration Growing up the value chain

Engineering Excellence CompanyName's USP to customers to win customers

Product Discovery Story mapping

Estimation

Project plan

User Experience

Metrics (What, How & Tools)

Inverting the testing pyramid Testing vs. Checking

Automated Unit testing

TDD/BDD

Automation

CI with static & dynamic code analysis, reporting, build staging

Clean Code (Craftsmanship) Design principles & patterns

Refactoring skills + Code smells

Coding conventions

Architectural patterns

Dev Ops TeamTools for Dev, Test & Process

Automation (beyond test automation)

Internal coaches (Network of change agents)

On-boarding (Org, Project, Level & Role)

Learning & Development


Agile DNATeam Collaboration

Cross functional self-sufficient teams

Project Wikis and Project handbooks

Continuous improvements, retrospectives, futurospectives

Collaboration games for running effective meetings

Information radiators in the team room

Appraisal process should be more team centric not individual centric. Add things like 360 Degree reviews.

Get first hand working experience with the candidate before hiring/rejecting them during the interview process

Building a learning culturePair Programming and Cross-functional pairing

Encourage generalizing specialists

Refactoring fests, design fest, hackatons, code retreat, coding dojos

Book clubs, library, open talks, Tech talks, user groups, conferences

Scratch your person itch day

Architecture council, SIGs, Tech Evangelists

Use game mechanics to drive the right behavior in employees


Clean Code (Craftsmanship) Fundamentals

Developers and Testers need to master these skills/conceptsDifference betweentesting v/s checking

black box v/s white box

happy v/s negative

unit v/s integration testing

API testing v/s GUI testing

DB testing, Performance testing, Load testing, Security testing, etc.

Basic unit testing skillsTools

Breaking dependencies between classes/layers (mocking/stubbing/simulators)

Unit Testing patterns


Clean Code (Craftsmanship) Fundamentals...

Continuous Integration process should automateCode quality checks like C3 (Coverage, Complexity & Churn)

Traceability

Static code analysis,

Dynamic code analysis

Reporting

Historical data/trends

Build Pipeline

Skills required for Simple DesignOO Design principles & patterns

Refactoring + Code smells

Coding conventions & idioms

Architectural patterns


Recommended .Net ToolsProductivity Tools - ReSharper

Unit Testing - NUnit, NUnitForms, MSUnit, Moq, MSpec, QUnit (JavaScript)

Behavior Driven Development - SpecFlow, Cucumber, FitNesse

Evolutionary Database Migration tool - Migrator.Net, MigSharp

Mutation testing - NinjaTurtles, CREAM, Nester

Build & Deployment - NAnt, nRake

CI Server - CC.net, Jenkins, Teamcity

Code Coverage - OpenCover/PartCover, NCover, dotCover

Other CI Tools: NDepend, FxCop, StyleCop

Version control - Git

Web Automation testing - Selenium , Sahi, Watir

WinForm Automation testing - White, Quail

Code Review - Barkeep, Reviewboard, Rietveld

https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools & http://crew-cr.org/

https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools

https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools


Pilot Projects


Need for Pilot Projects

Trying to change the whole company is a long process. We first need to create some internal success stories on real (different) projects to

Get other team’s buy-in

Create sales & marketing collaterals

Mine out patterns that work in our company/culture

Rapidly create expertise & local champions

Create some case studies & a platform for team members to learn about the new way of working

Use these pilot projects to constantly push the envelope on the process & innovation side

Minimize the risk of things going out of control. Also formulate a transition strategy (we’ve seen many company fail miserably when they try to do a big-bang roll out)


Pilot Project - High Level Plan

1-2 Months 3-4 Months 5-6 Months

Iden

tity

2 Pi

lot P

roje

ct +

Team

Mem

bers

Esta

blish

a w

orki

ng re

latio

nshi

p w

ith C

ompa

nyN

ame W

ay te

am

Basic

Agil

e+de

velo

pmen

t pra

ctice

s tra

inin

g

Get

ting

a sim

ple

proc

ess/s

truc

ture

in p

lace

Kick

off

proj

ect w

ith a

pro

duct

disc

over

y &

stor

y m

appi

ng w

orks

hop

Intr

oduc

e BD

D to

the

team

Impr

ovin

g C

ode

Hyg

iene

& A

utom

ated

Test

ing

(on

exist

ing

proj

ect)

Setu

p a

CI p

roce

ss w

ith a

ll th

e ne

cess

ary

tool

s int

egra

ted

Kick

-off

one

mor

e pi

lot p

roje

ct

Gain

ing

in-d

epth

und

erst

andi

ng o

f pra

ctice

s

Esta

blish

ing

foun

datio

nal d

evel

opm

ent (

XP)

pra

ctice

s

Min

e ou

t pat

tern

s fro

m th

e pi

lot t

eam

s

Stan

dard

ize c

ode

quali

ty &

pro

ject

trac

king

met

rics a

long

with

SQ

A

Train

ing

on E

volu

tiona

ry d

esign

& re

fact

orin

g to

pat

tern

s

Intr

oduc

e TD

D to

the

team

Setu

p a

small

Dev

-ops

team

Star

t bui

ldin

g ca

se-s

tudy

& m

arke

ting

colla

tera

l

Star

t with

Org

. wid

e Agil

e &

XP

train

ings

Kick

-off

the

last p

ilot p

roje

ct

Beco

me

profi

cient

with

all

the

deve

lopm

ent (

XP)

pra

ctice

s

Refin

e pa

ttern

s pul

led

out f

rom

all

the

pilo

t tea

ms

Get

as c

lose

to C

ontin

uous

Del

ivery

as p

ossib

le

Refin

e co

de q

ualit

y &

proj

ect t

rack

ing

met

rics

Shar

e in

form

al le

arni

ng p

atte

rns f

rom

the

vario

us p

ilot t

eam

s

Pack

age

case

-stu

dy &

mar

ketin

g co

llate

ral

Starting Jan Initiatives started in 1st Month continue.

Feature Teams

Evolutionary DesignIdentify people to be real change agents/coaches.

Identify & Coach 2 Pilot Teams to create Success story.

Focus on Code Hygiene

Basic OO Skills training and mentoring for Devs

Overall Product level Test

Coach Testers to build-quality-in-the-process

Test-First Development

Test Driven Development

Automated Builds

Team level Continuous Integration with Automated Tests & Code Quality Metrics

CI across Product Teams

Writing Effective Stories

1st Month 2nd Month 3rd Month 4th Month

100% Automation

Continuous Deployment

Acceptance Criteria

Slicing Stories

Pair Programming

Value Stream Mapping

Managing Legacy Code

Design Bootcamp Training

Effective Planning

Story Point Estimation

Capacity Planning

Standup Meetings

Retrospectives

Mistake proofing skills for Testers

Special Interest Groups

Refactoring Legacy Code

Design Patterns Training

Focus on Flow

Detailed Plan

Starting Jan

Zero Downtime Deployment

XP Practices Overview

Self-Organized Teams

Product Discovery Workshops

Initiatives started in 1st Month continue.


To Achieve this Plan

Identify one person to play the Strategic Agile Coach role.

More internal coaches should be identified to help this coach.

Start with 2 Pilot projects. Two coaching models available:

Option 1: Hire an Expert full-time Agile(Scrum/XP/Kanban) Coach to coach 2 pilot teams.

Option 2: Hire a part-time Agile/Scrum/Kanban Coach + One full-time XP Coach to help coach 2 pilot teams.

Quite a lot of training on the following topics will be required to scale this org. wide:

Agile Overview workshop

Product Discovery & User Story Mapping workshop

OO Bootcamp & Design Principles & Patterns workshop

TDD & BDD workshops

Refactoring Legacy Code workshop

Test Automation and Exploratory Testing workshop


Thank You!

Naresh [email protected]

@nashjain http://nareshjain.com





agile assessment report - agilefaqs - expert agile, scrum ...€¦ · summary of our visit ......

Documents