A CTOs Perspective on Agile

3. Who am I? • Bradley D. Brown • Today http://bradleydbrown.blogspot.com • InteliVideo in April 2012 • Founder • Video Monetization Platform • TUSC in 1988 • Built it to sell training online • Sold to Rolta in 2008 • Focused on mid and long tail and corporate deals • IntelliReal in 2005 • ApEx provides a “quick turns” • Sold to Equifax in 2011 approach to our offerings • 10+ other companies, boards • Just me so far… • Professor – DU • Advisor for Founders Institute • Author – 6 technical books

4. Using Agile • Used it at IntelliReal first • Rolta bought TUSC • I ran iPerspective product development team • Brought it to our team • International team • Plenty of consulting, reviewing companies, etc. • InteliVideo

5. Agile 101 Education Topics: • Scrum Pillars • Product Owner • Product Backlog • Sprint Planning • Delivery Team • Daily Meeting • Sprinting • Reporting • Retrospective

6. Sprint Planning – Sample Agenda • Opening, Welcome, Intros, Agenda • Product Vision & Roadmap • Development Status, Architecture, Previous Sprint • Velocity In Previous Sprints • Team – Availability and Capacity • “Done” Review Definition • Product Backlog: Review and Select • Tasking Out – Estimates – Ownership • Challenges – Dependencies – Risks • Review: Capacity Required • Review: Risks & Mitigations • COMMIT! • Parking Lot, Action Items • Close

7. What it is…(good for)… • Delivering product to customers • Backlog is always there – never lacking tasks if you • Providing frequent releases get ahead of schedule or (quick turns) to get feedback priorities change • Never long of a wait for highest • Development teams get priority work – provides bite-size into cadence chunks for everyone to see progress • Points out that most developers aren’t good at • Great visibility to who’s doing estimating time required what on the team • Team output tends to • Nobody escapes delivering and remain consistent vs. death if they can’t deliver, they self- marches of waterfall select out – nobody can hide

8. More Good • Cult-like belief that Agile is better • No Hijacking - Developers are than waterfall not interrupted by other assignments that weren’t • Better for developers agreed to in sprint planning • Better for management • Provides for rapidly changing • Daily scrums provide requirements or technology • Everyone’s current on status changes (new versions) • Good for chickens and pigs • Waterfall assumes requirements are all known • Saves additional meetings, up-front, won’t change, writing status reports, etc. etc…not always true • Day is focused on development • Strong “peer” feeling in teams and testing which creates cohesion – • Vacation time is always known everyone’s equal

9. What Managers (CIOs, CTOs) Like • Complete transparency into your • Get to Revenue faster – speed team to market is increased • Ability to measure team velocity • Higher quality products because testing is integrated • Iteration retrospectives fine-tune throughout lifecycle - Fewer agile process defects since testing is • Demo to product owners every involved immediately iteration to get instant feedback • Flexibility / Agility – no big • Reduce project risk by finding spec up-front, design and issues much sooner develop as customer requirements demand • You end up with the “right” product • MUCH more enjoyable – high performance, highly motivated team

10. What it Ain’t… • Often more difficult to implement than people think it will be • It’s tough to nail down a true “delivery” date for a product release – team uses Agile as an excuse – that’s not part of the process – we don’t know yet… • Managing the backlog is a full time job – things are in that shouldn’t be – and who will do this? • Tools like Rally can become a burden • Backlog and other information in the tools can consume you

11. What it ain't • It can be hard to prioritize if everything is a high priority in such a small time box • Developing truly releasable products every iteration is tough • Providing the correct amount of product requirements for a given development team can be difficult. This is where acceptance tests really prove valuable. • If not used properly, project management tools are completely useless at one end of the spectrum or become handcuffs at the other end.

12. Best practices • Understand the capabilities of the • Successful agile projects typically need to rely upon development team down to the adoption of other tools and individual developer. Some practices. developers require very little detail and thrive on the freedom to • Continuous integration and thorough automated testing create while others need very practices are needed to build a complete requirements and excel better safety net under the more at building them out with speed frequent releases. and efficiency. • Other tool options.. • Product management tools are o Jira not out-of-the-box solutions. They need to be fine tuned for a o Basecamp process that works with each o Google Apps team. o Whiteboards

13. Global Teams and Agile • Tried to run completely globally • Easier when everyone’s in the – daily scrums to retrospectives same room for planning and participating in ad-hoc • Someone was always discussions inconvenienced with the time • Not really an “Agile” issue, it’s • Usually the US team just tough regardless • 10pm or 5am • We went to the US doing one • Lack of face time makes it set of development and India tough doing another completely • Product owners much spend different set of deliverables extra time providing details • Then we forked the code – this stories and requirements was a mistake!

14. Questions?

15. Special Thanks • Thanks to Steve Meyers, Chris Klein, Franz Garsombke, Bill Bauernschmidt and Gregg Petri for their help on this presentation – I couldn’t have done it without them!

16. Copyright Information • Neither InteliVideo, Rolta nor the author guarantee this document to be error-free. Please provide comments/questions to brad@intelivideo.com. • InteliVideo and Rolta © 2012. This document cannot be reproduced without expressed written consent from an officer of InteliVideo or Rolta.

Editor's Notes

Steve MAgile is good:For delivering product to customers – I’m thinking here about projects for defined system functionalityProvides frequent releases to allow integrating customer feedback and changesAllows customer to refine their requirements more quickly and get what they wantNever too long of a wait for highest priority workFor managing expectations of non-technical execsProvides ‘bite-size’ chunks of what is being deliveredNever too long of a wait for highest priority workFor transparency into dev teams who is doing what priority of backlog workno place for developers to ‘hide’ – individual performance is obviousDevelopment teams get into a cadence or rhythm after a few iterationsAmount of work that fits into an iteration gets more accurate over time reducing broken promisesLess frequent death marches for dev team means everyone stays energized and the team output remains consistent Gregg PetriAgile project management certainly receives a lot of buzz, especially from the true believers who feel that people would be crazy to run a software project any other way. Having worked for many years on both successful waterfall and Agile projects, I tend to look at the approach more objectively than others. There is certainly much to love about Agile, especially for programmers. The daily scrums, if followed properly, are very useful in keeping all of the team members – both chickens and pigs – current on the latest status. The development team is not further bogged down by additional meetings or writing status reports, and can use nearly all of the day to focus on development and testing tasks. Developers are also not interrupted with other assignments not agreed to during the sprint planning sessions, and can work heads-down with the other developers exclusively on the committed tasks. For projects with rapidly changing requirements, as most software projects seem to be these days, Agile allows the team to change course quickly to satisfy new or changed requirements, or even respond to changes in technology. Large waterfall projects assume all requirements are known up front, requirements rarely change, and developers can reliably estimate the work effort, all of which we know to be rarely the case. I also personally like the peer feeling of the scrum teams where everyone on the team is an equal for the duration of the sprint, which seems to be a stronger sense of teamwork and cohesion. FranzPros: Complete transparency into your teamAbility to measure team velocityIteration retrospectives fine-tune agile processDemo to product owners every iteration to get instant feedbackReduce project risk by finding issues much soonerFewer defects since testing is involved immediatelyBill BSuccessful agile projects typically need to rely upon adoption of other tools and practices. Continuous integration and thorough automated testing practices are needed to build a better safety net under the more frequent releases.http://www.allaboutagile.com/10-good-reasons-to-do-agile-development/10 Good Reasons To Do Agile Developmentby Kelly Waters, 11 June 2007 | Agile Adoption, Agile Project ManagementHere are 10 good reasons to apply agile development principles and practices…1. RevenueThe iterative nature of agile development means features are delivered incrementally, enabling some benefits to be realised early as the product continues to develop.2. Speed-to-marketResearch suggests about 80% of all market leaders were first to market. As well as the higher revenue from incremental delivery, agile development philosophy also supports the notion of early and regular releases, and ‘perpetual beta’.3. QualityA key principle of agile development is that testing is integrated throughout the lifecycle, enabling regular inspection of the working product as it develops. This allows the product owner to make adjustments if necessary and gives the product team early sight of any quality issues.4. VisibilityAgile development principles encourage active ‘user’ involvement throughout the product’s development and a very cooperative collaborative approach. This provides excellent visibility for key stakeholders, both of the project’s progress and of the product itself, which in turn helps to ensure that expectations are effectively managed.5. Risk ManagementSmall incremental releases made visible to the product owner and product team through its development help to identify any issues early and make it easier to respond to change. The clear visibility in agile development helps to ensure that any necessary decisions can be taken at the earliest possible opportunity, while there’s still time to make a material difference to the outcome.6. Flexibility / AgilityIn traditional development projects, we write a big spec up-front and then tell business owners how expensive it is to change anything, particularly as the project goes on. In fear of scope creep and a never-ending project, we resist changes and put people through a change control committee to keep them to the essential minimum. Agile development principles are different. In agile development, change is accepted. In fact, it’s expected. Because the one thing that’s certain in life is change. Instead the timescale is fixed and requirements emerge and evolve as the product is developed. Of course for this to work, it’s imperative to have an actively involved stakeholder who understands this concept and makes the necessary trade-off decisions, trading existing scope for new.7. Cost ControlThe above approach of fixed timescales and evolving requirements enables a fixed budget. The scope of the product and its features are variable, rather than the cost.8. Business Engagement/Customer SatisfactionThe active involvement of a user representative and/or product owner, the high visibility of the product and progress, and the flexibility to change when change is needed, create much better business engagement and customer satisfaction. This is an important benefit that can create much more positive and enduring working relationships.9. Right ProductAbove all other points, the ability for agile development requirements to emerge and evolve, and the ability to embrace change (with the appropriate trade-offs), the team build the right product. It’s all too common in more traditional projects to deliver a “successful” project in IT terms and find that the product is not what was expected, needed or hoped for. In agile development, the emphasis is absolutely on building the right product.10. More Enjoyable!The active involvement, cooperation and collaboration make agile development teams a much more enjoyable place for most people. Instead of big specs, we discuss requirements in workshops. Instead of lengthy status reports, we collaborate around a task-board discussing progress. Instead of long project plans and change management committees, we discuss what’s right for the product and project and the team is empowered to make decisions. In my experience this makes it a much more rewarding approach for everyone. In turn this helps to create highly motivated, high performance teams that are highly cooperative.Implications of embracing agile development principlesBut there are implications. There’s no such thing as a free lunch! And there’s no magic bullet for software development. Sorry, no, you can’t just drink the cool aid :-) In exchange for all these benefits, you do get less predictability, software and humans are still difficult, you can’t blame someone else if things don’t go right, and it generally requires much more commitment and effort from everyone involved – i.e. teamwork is even more important.Nevertheless, the advantages of agile development are really compelling.Chris Khttp://blog.utest.com/is-agile-really-worth-the-trouble/2012/07/?ls=Newsletter&cc=fr&mc=July_2012-ProspectIs Agile Really Worth the Trouble?If development methodologies were a religion – and depending on who you’re talking to, they are – we here at the uTest blog would be agnostic. That is to say we believe no methodology is inherently better than another. As we’ve learned from our customers, almost any approach can work given the right personnel.That said, there seems to be a strong preference among the industry’s movers and shakers for the Agile methodology. Seen as a more flexible and efficient approach, Agile is now entrenched in dev and testing shops all over the world for a number of reasons – too many to list here. But what if all those reasons are wrong? What if Agile isn’t really more efficient? What if Agile is actually – gasp! – a hindrance to dev and test teams?That’s the case being made by analyst firm Voke, who just published a report on the hidden (and not-so-hidden) costs of the Agile methodology. In “Market Snap: Agile Realities” they summarized the experiences of over 200 companies who had recently transitioned to Agile. Here are a few clips of what they found, courtesy ofTechWeekEurope:Out of over 200 participants, 64 percent said that switching to Agile Development was harder than it initially seemed. Forty percent of respondents did not identify an obvious benefit to the practice. Out of those who did,14 percent thought it resulted in faster releases, and 13 percent – that it created more feedback. Seven percent of participants noted that Agile developers were happier due to reduced future planning and documentation.According to Voke, since the global financial crisis of 2008, the average cost of software projects has seen a sharp rise, even though developer teams have become smaller and the deadlines tighter. Meanwhile, the risk of software failures associated with Agile Development has remained high.“While many people assume that Agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. They may not realize that today’s solutions are tomorrow’s problems,” said Theresa Lanowitz, lead analyst at Voke.Is this a problem with Agile or with implementation of Agile? In other words, are they doing it wrong? I’ll leave that for you to decide. In the meantime, here’s Elisabeth Henderickson with her explanation of ”fake agile” from a past Testing the Limits interview:When I meet victims of fake agile, my first advice is to stop accepting the role of victim. No matter what our role in an organization, we have the power of influence. We can educate our colleagues and managers about the difference between fake and real agile. And we can help the key business decision makers understand that if they want the potential benefits of agile — capabilities delivered sooner at higher quality — they have to support the practices that provide those results and not just support “compress the schedule” and “change everything up to the last minute”.To close, I’d like to focus on one Agile problem area – the transition – and propose a solution. It’s clear from the report (and countless other sources) that transitioning to to Agile may be the most difficult aspect of the methodology. This makes sense, especially for teams that had become stuck in their ways. So, to help make that process a little smoother, I’d like to revisit a solution from eBay’s Jon Bach called Agile-Fall.“Agile-fall” refers to having the principles associated with Agile (daily stand-ups, sprints, burndown charts, etc.), done in a waterfall-y series of development steps. Example: Sprint 1: Gather requirements, Sprint 2: Design your tests, Sprint 3, Run those tests, Sprint 4, Fix bugs, Sprint 5 regress those bugs. There’s no shame in that if that’s what works, and when you’re going through a transition from Waterfall to Agile, that may be the best thing as opposed to a sudden lever-pull one day where you show up and your desk is next to someone else with no walls and there’s a stack of sticky notes and markers on your chair with an email to report to your first standup in 30-minutes.What do you think? Is Agile worth the costs? Let us know in the comments section
Steve MAgile has some challenges: For managing R&D type work - Agile is still a good foundation and iterations are good, but the release schedule is often very different from traditional project work. IMHO the Kanban flavor of agile is more appropriate for this type of work as it allows for prioritization with more open-ended end times that are often the case with R&DManaging backlog properly is a full time job for a team of more than a few people – that overhead is sometimes hard to absorb (either financially by hiring dedicated resource or by adding that work onto existing roles)Long term planning requires time and attention to the backlogI find quarterly group meetings to lay out the themes for the current quarter and one quarter out help a lotManaging multiple or large teams in an agile environment can be tricky. Again this needs some dedicated roles for scrum masters/product owners. Gregg PPerhaps I am getting old and "stuck in my ways" but there are things about Agile I don't particularly like. I have seen scrum meetings become overly routine where no real or useful information is exchanged, developers do not adequately update their hours and task status even using very lightweight tools like Jira (with Greenhopper) or Agilefant, and product owners do not step up to write detailed users stories prior to the sprint planning meetings. I also have a tendency, perhaps unfairly, to view Agile development as a path to mediocrity. Working in an Agile environment, developers take a very short-term view of the system, only estimating the effort to complete tasks during the upcoming 2-4 week sprint, and might make decisions that satisfy near-term requirements but turn out to be bad architectural decisions in the long-term. If developers were forced to think out the software changes beforehand by fully performing impact analysis before ever writing a line of code, the overall design might be better than just solving the next piece of the puzzle (so to speak). Since Agile doesn't seem to incorporate much impact analysis or overall design work, it seems that the only goal is to crank out code quickly. Without careful oversight of the project manager, unit testing might be minimal, and documentation is often weak or non-existent. Teams must carefully choose which tools to use, if any, since tools like Rally add more work than they're worth, and don't seem to handle those tasks that are started but not finished during a sprint. We used Jira for iPerspective, which the team found much more useful. Looking at iPerspective, we always used Agile development but in the end were not successful. After a few years of no customers, morale dropped to the point where scrums were pointless. During that time the team had become fragmented, each working on separate initiatives rather than on the same stories with our resources stretched too thin, and only towards the end did we escape the chaos and start working cohesively again. I guess my main frustration is that Agile allowed us to continuously build software and pursue interesting and promising ideas, but the team never seemed to want to ever release an official version with all of the "not quite as fun" stuff that goes along with it. Rather, the team enjoyed building and building with no real idea on how we would support multiple versions of the software and perform code maintenance if we ever did sell it as a product. I have to believe that there are many successful Agile teams out there who are building great products and rapidly responding to changing marketing requirements and customer needs. In order for those projects to succeed, I believe those teams must have strong product owners, development teams who are committed to quality and are able to meet their deadlines, and test teams who can automatically regression test the daily builds to comprehensively test every aspect of the rapidly changing code line.FranzCons:Not everyone can handle the rapid pace of delivering software each iteration. Mediocre developers have a really difficult time.No detailed design makes estimating a very large project more difficult.Bill BOne of the challenges I would add is needing the right people, with the right skills and mindset, on the agile team to be successful. They need broader skill sets to handle different aspects of a project instead specializing in narrow areas. They also need to be willing and able to switch between roles (development, DBA, QA, devops, etc... ) when needed, and not just expect to be done when they check their code in. Break down the silo's...http://www.allaboutagile.com/disadvantages-of-agile-development/ Disadvantages of Agile Developmentby Kelly Waters, 4 September 2007 | Agile AdoptionDon’t get me wrong. I’m a big fan of agile development. If you’re a regular reader of my blog, you’ll know that :-)But I’m not so pro-agile that I’ve lost all sense of balance. An agile approach to development is good for so many reasons. But agile development does require certain things that can also be a disadvantage.If you’re thinking of adopting agile principles, it’s important that you know what you’re in for. You need to be sure that you, your project team and the management supporting your project all understand these trade-offs, and are happy to accept and support them in preference to a more traditional approach.Here’s my list of potential disadvantages with agile:Active user involvement and close collaboration are required throughout the development cycle. This is very engaging, rewarding and ensures delivery of the right product. It’s the fundamental principle in agile that ensures expectations are well managed. And since the definition of failure is not meeting expectations, these are critical success factors for any project. However these principles are very demanding on the user representative’s time and require a big commitment for the duration of the project.Requirements emerge and evolve throughout the development. This creates the very meaning of agile – flexibility. Flexibility to change course as needed and to ensure delivery of the right product. There are two big flip sides to this principle though. One is the potential for scope creep, which we all know can create the risk of ever-lasting projects. The other is that there is much less predictability, at the start of the project and during, about what the project is actually going to deliver. This can make it harder to define a business case for the project, and harder to negotiate fixed price projects. Without the maturity of a strong and clear vision, and the discipline of fixing timescales and trading scope, this is potentially very dangerous.Agile requirements are barely sufficient. This eliminates wasted effort on deliverables that don’t last (i.e. aren’t part of the finished product), which saves time and therefore money. Requirements are clarified just in time for development and can be documented in much less detail due to the timeliness of conversations. However this can mean less information available to new starters in the team about features and how they should work. It can also create potential misunderstandings if the teamwork and communication aren’t at their best, and difficulties for team members (especially testers) that are used to everything being defined up front. The belief in agile is that it’s quicker to refactor the product along the way than to try to define everything completely up front, which arguably is impossible. And this risk is managed closely through theincremental approach to development and frequent delivery of product.Testing is integrated throughout the lifecycle. This helps to ensure quality throughout the project without the need for a lengthy and unpredictable test phase at the end of the project. However it does imply that testers are needed throughout the project and this effectively increases the cost of resources on the project. This does have the effect of reducing some very significant risks, that have proven through research to cause many projects to fail. The cost of a long and unnpredictable test phase can, in my experience of waterfall, cause huge unexpected costs when a project over-runs. However there is an additional cost to the project to adopt continuous testing throughout.Frequent delivery of product and the need to sign off each feature as done before moving on to the next makes UAT (user acceptance testing) continuous and therefore potentially quite onerous. The users or product owner needs to be ready and available for prompt testing of the features as they are delivered and throughout the entire duration of the project. This can be quite time-consuming but helps drastically to ensure a quality product that meets user expectations.Finally, common feedback is that agile development is rather intense for developers. The need to really complete each feature 100% within each iteration, and the relentlessness of iterations, can be mentally quite tiring so it’s important to find a sustainable pace for the team.I believe these trade-offs are well worthwhile. Software is complex. People are complex. And the only thing that’s certain in projects is change. This lethal combination of unpredictability is more often than not helped by agile principles. So, in my view, for many project situations, the advantages of agile development far outweigh the disadvantages.
I think global teams have unique issues outside of agile. Agile can work well with a global team IF the team members are all up to speed on the codebase and have the tools and ability to problem solve effectively through online tools. IMHO the biggest issue with global teams is the lack of face time with each other. Unless there are dedicated product owners who can spend the extra time to be extremely detailed in stories, requirements often get missed. So many issues are averted by people being in the same room for planning and by participating in ad-hoc discussions.

A CTOs Perspective on Agile

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to A CTOs Perspective on Agile

Similar to A CTOs Perspective on Agile (20)

Recently uploaded

Recently uploaded (20)

A CTOs Perspective on Agile

Editor's Notes