Don't just do agile, do it right! - Simon Storm + Mary Lynn

Editor's Notes

1. Simon Storm – Director of Enterprise Applications – Mary Lynn – Director of Product Management – MVP Conference – Artisphere KEYNOTE 5 things outside of the Scrum Today we are going discuss 5 things outside of the scrum team that will dramatically improve your chances for a successful Agile implementation I don’t want to diminish the importance of the team. We have an incredible group who have learned, adapted and thrived Simon Storm – Director of Enterprise Applications – Mary Lynn – Director of Product Management – As far as I am concerned, we are giving the keynote.
2. Financial services organization Over 3000 financial institutions Unique challenges - major banks to tiny community banks AS400 – RESISTANT TO CHANGE Successfully adopted Agile, Continuous Delivery, Infrastructure as Code and working towards DevOps
3. Waterfall Mistakes Business needs change Missed requirements Gold plating because of duration Agile Return on investment earned earlier Feedback (customer, application, etc) continually incorporated Analysis & Design is continuous Unneeded features are never built
4. Product Owner is the key Backlog = Features = Stories = CONTINUALLY GROOMED Finished work is reviewed
5. THIS IS NOT IDEAL You don’t want to cause this You don’t want to feel like this Parents were not prepared. Amazon didn’t deliver Tickle Me Elmo in time. Bad daddy The early warning - of an Agile team – falling apart Failing to prepare for PLANNING SESSION – ALL DONE NIGHT BEFORE BAD SURPRISE - Team has no idea what is coming Done by one person in a vacuum Can’t plan in a day NEED A STRONG PRODUCT OWNER WHO IS INVOLVED = MARY LYNN IS A PERFECT EXAMPLE OF A EXCEPTIONAL PRODUCT OWNER There is nothing worse than disappointing your kid on their birthday LACK OF PREPARATION – LACK OF UNDERSTANDING THE DESIRED OUTCOME Children want to open a present and then immediately play with the present. Unprepared Parent: Open present followed by hours of cursing the manufacture who decided to ship a toy in the lowest common denominator Prepared Parent: Wraps empty boxes. The early warning that I no longer miss is that of an Agile team who is starting to fall apart Preparation for upcoming sprint planning is done the night before…. All the work is done by one person in a vacuum Planning is a surprise to all of the attendees A full day is no where near enough time to complete the planning process
6. EXPERTS ON WHAT NOT TO DO EXCELLA RAN THROUGH NUMEROUS CONSULTANTS AND TRAINING SESSIONS BUT MADE US SMARTER WITH EACH FAILURE
7. STUCK WITH IT AND SUCCEEDED QUARTERLY TO BI-WEEKLY RELEASES ELIMINATED WEEKEND WORK – INCREASED TEAM MORALE MAXIMIZED THE AMOUNT OF WORK NOT DONE DELIVERED FUNCTIONALITY TO CUSTOMERS MORE QUICKLY TOP 5 THINGS YOU CAN DO OUTSIDE OF THE SPRINT TO MAKE AGILE WORK
8. 15 Minutes daily Each person takes a row on the board and moves user stories across it. Prefer the low-tech sticky notes and painters tape so….. They are not considered ready to be moved into a sprint until: UX review Acceptance Criteria Written Text Reviewed Designs done And….
9. WHO USES 3 AMIGOS? STORIES CAN’T BE ACCEPTED WITHOUT 3 AMIGO The three amigo consists of a developer, business analyst, and QA reviewing a story. The BA, representing the product owner, presents the story, and the three of them work together to refine it and identify any missing requirements or edge cases. PRE AMIGO, RE-AMIGO…
10. Here is an example of an analysis we did of some user stories being prepped for a sprint: EXPLAIN PICTURE SAVES TIME AND MONEY ON BUILDING THE WRONG FEATURES YOU GET TO KNOW YOUR CUSTOMERS BETTER TOOLS CAMTASIA, INVISION, BALSAMIQ, PHOTOSHOP, USERTESTING.COM
11. STAY CLOSE TO YOUR TEAM. THEY ARE NOT ORDER TAKERS. SMARTER THAN YOU. UNDERSTAND HOW THEY OPERATE AND LISTEN TO THEIR IDEAS. IN ADDITION TO COMMUNICATING DIRECTION AND STAKEHOLDER NEEDS, ROLL UP YOUR SLEEVES WITH THE TEAM. PARTICIPATE IN SOME ESTIMATING EXERCISES Why is this taking so long? I was planning on getting all of these features done and you only got a few done ATTEND RETROS
12. LEAN CONCEPT –MEASURE AND LEARN Measure the success of each feature you deploy so that you can learn and adjust the feature, if necessary. Despite your best prototype testing, you may learn that the majority of users are not using something in the way it was intended. While not great, at least you know and can adjust. EXPLAIN HEAT MAP GOOGLE ANALYTICS, CLICKTAIL
13. WE BUILT HIGHLY CONFIGURABLE APPLICATION – When we knew the least Configurable parts never changed 3 developers to make a change Simple changes were difficult ANYONE can implement a full feature. RINSE – Removed SOAP (Web Services Tier) SIMPLY THE INFRASTRUCTURE–Dev is a world apart from Production SIMPLY THE ENVIRONMENT – Co-location, get rid of multiple hats, AGILE DIDN’T WORK FOR US – AGILE was not set up to succeed SPRINT 0 One of my favorite catch phrases is “At the beginning of the project is when you know the least” One of the most prevalent comments I hear is “Agile didn’t work for us”. Mary Lynn ran through several team and process points that are critical to success. But there is a technical component as well that needs to be considered. The main issue with infrequent releases is the need to get the feature in now which results in gold plating. A second symptom that becomes apparent is the need to create a very dynamic and highly configurable system While this sounds like a good idea, it is detrimental when done “when you know the least”. We fell into the trap of creating dynamic listings so we could add fields as needed. The issue we ran into was adding dynamic fields was very difficult, creating logical layouts was difficult and making changes to text on the pure website was difficult We had a situation where we needed the database guy to do update a stored procedure, a the services guy to update the web service, and then the developer could implement the functionality, but before it was complete it would go to the UI guy to clean up the screen. You cannot be agile if this is the only way to add a feature.
14. EVERYONE WANTS 2 WEEKS 2 WEEKS  8 WEEKS  2 HOURS We deploy code every other week – Amazon Deploys 11.6 seconds Small changes are easier to digest Small changes reduce the risk of introducing issues We made migrating a development task and a non-event It was well planned to do this slide last. I can speak for hours on this topic. The main challenge that we faced was the two week syndrome BAs wanted 2 weeks to define requirements Developers wanted 2 weeks to code QA wanted 2 weeks to test Operations wanted 2 weeks to ensure production readiness I wanted the team to perform 2 week sprints Mary Lynn already explained the importance of backlog grooming which really means that all the BA work should be done prior to the start of the sprint. She also mentioned the importance of small stories. This cuts the 8 weeks back to about 4. Still too long. The solution is Continuous Delivery. First, by automating deployments, building confidence and making the deployment process a routine non-event Confidence comes from consistent deployments, but Infrastructure as Code is really the key to creating consistency Slow Delivery IT cannot keep up with business demands Resistance to changing requirements Manual Testing QA tests the same functionality over and over Developers move on to new tasks and then have to switch gears to fix bugs Manual Deployments Long detailed ECS documents Inconsistent environments Scheduled releases for off hours
15. In the end, it’s up to you to give your kid the birthday they deserve and to give your customers high value products they love. Agile can help you get there. Don’t give up if you screw up. Just try again and you’ll get there. It’s definitely worth it. Thank you for giving us the opportunity to share some of our failures and successes with you today. Simon and I love talking about this so please feel free to grab us later if you have any questions.