Topic
  • 8 replies
  • Latest Post - ‏2013-02-22T16:46:39Z by dsparacin
HazelWoodcock
HazelWoodcock
10 Posts

Pinned topic Virtual Roundtable - Agile Government: Agile Development

‏2013-02-19T09:51:05Z |

Agile Government Virtual Roundtable

 
Welcome to this round table discussion which will run until Tuesday 26th February.
In this thread we are discussing Agile Development.
  • Moving from waterfall to agile
  • The role of modular development
  • challenges in the government environment
  • success stories from the government agencies

You will need to JOIN this group to reply to this topic.
 

Other Conversations Adopting Governance Digital Strategy

Help

Updated on 2013-02-22T16:46:39Z at 2013-02-22T16:46:39Z by dsparacin
  • elizabethwoodward
    elizabethwoodward
    9 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-20T20:11:28Z  
    "How is time fixed in Agile? I mean, if someone says we have a year to produce this software. If a team of developers in slow/new, do we just have few features at the end?"
     
    In agile, we select a fixed time box of a month or less. (We have many teams that work on 2-week iterations.) We break our work down into capabilities that can be delivered in small bites within that fixed time box. We find ways to split larger features into smaller pieces that take a slice through the entire stack (interface, database, web services, etc.). That helps the team to get a better sense of where the challenges are and it helps to reduce risk. As you said, a new team might be able to deliver less at the beginning... within the earlier time boxes.... but that improves over time as the team learns to work together and implements continuous improvement. If the time box is one month, every month you'll see capability delivered and have a good sense of how the team is progressing. The goal is to have releasABLE software at the end of each iteration, though a business may decide to only release when they've achieved a certain set of capability targeted for a release.
  • tammykulesa
    tammykulesa
    7 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-20T20:36:06Z  
     How does Quality stay high when a project has integration features/components that require substantial time to complete?"
    Updated on 2013-02-20T20:36:06Z at 2013-02-20T20:36:06Z by tammykulesa
  • tammykulesa
    tammykulesa
    7 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-20T20:36:14Z  
    "How is time fixed in Agile? I mean, if someone says we have a year to produce this software. If a team of developers in slow/new, do we just have few features at the end?"
     
    Updated on 2013-02-20T20:36:14Z at 2013-02-20T20:36:14Z by tammykulesa
  • Steve_Crago
    Steve_Crago
    3 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-21T08:53:20Z  
     I recently joined a State Government project that has been using the concept of 2-week iterations.  The proponents of this process are not experienced in agile, they know the terminology just not the practical application, so things have gone awry. The problem started when management dictated the number of stories per iteration, instead of allowing the teams to be self-governing.  While the teams have been completing the stories, the defect rate is unacceptably high, in my opinion. 
     
     I'm slowly educating management and the teams on various aspects of agile processes.  I've got them to consider the idea of a one-day Sprint (aka Iteration) Planning meeting, instead of spending several days out of the 2-week iteration trying to analyze the stories.  I'm also teaching them how to track progress by using a Kanban board.
  • ScottAmbler
    ScottAmbler
    24 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-21T13:59:55Z  
     How does Quality stay high when a project has integration features/components that require substantial time to complete?"
     Tammy, I think you'll find my article Agile Quality and Testing Strategies: Disciplined over Rhetoric to be a good overview of how disciplined agile teams approach quality issues.  There are a lot of techniques available to you, but they generally require a different set of skills than what you see in the traditional world.  You'll likely need to get some coaching and mentoring if you want to be successful.
  • RolfWReitzig
    RolfWReitzig
    2 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-22T15:29:26Z  
    "How is time fixed in Agile? I mean, if someone says we have a year to produce this software. If a team of developers in slow/new, do we just have few features at the end?"
     
    Tammy, great question and one that drives management crazy when they face the realities of "going Agile".
     
    From an Agile point-of-view, predicting when software will be delivered is an extremely inexact science and difficult at best.  Experience and project results across the board conclusively demonstrate that.  So, instead of deceiving ourselves, management, and customers with fantasy delivery dates, why don't we take a more incremental approach that focuses on delivering the most business value early on, and ensuring, to the best of our ability, that we can deploy/ship/use the software after every iteration?  Once we have a history of how the team is performing, we can become more confident in our ability to predict delivery dates.
     
    So, the answer to your question, if the team is "slow/new", yes, you will receive fewer features than expected.  The good news is that they will be the highest priority features delivering the most business value.  As an editorial note, most issues around teams suffering from lower productivity are not related to them being slow/new.  They typically are related to other issues around management setting delivery dates, too much work being shoe-horned into too little time, poor software quality, and time-consuming rework that results.
     
    Agile basically turns the paradigm upside down, which is why its hard for many organizations to become Agile and realize the benefits.  
  • dsparacin
    dsparacin
    2 Posts

    Re: Virtual Roundtable - Agile Government: Agile Development

    ‏2013-02-22T16:46:39Z  
     I recently joined a State Government project that has been using the concept of 2-week iterations.  The proponents of this process are not experienced in agile, they know the terminology just not the practical application, so things have gone awry. The problem started when management dictated the number of stories per iteration, instead of allowing the teams to be self-governing.  While the teams have been completing the stories, the defect rate is unacceptably high, in my opinion. 
     
     I'm slowly educating management and the teams on various aspects of agile processes.  I've got them to consider the idea of a one-day Sprint (aka Iteration) Planning meeting, instead of spending several days out of the 2-week iteration trying to analyze the stories.  I'm also teaching them how to track progress by using a Kanban board.
     Hi Steve,
     
    Yes, a Sprint planning session  is absolutely required at the beginning (or end) of each sprint. Demo, retrospective, and then planning for next Sprint.
     
    In addition to the Sprint planning sessions you probably need to be doing "story grooming" on a continual basis.
    In story grooming you work on getting stories prioritized and defined well enough by your product owner so the team can assign story points/complexity. Once you have these 3 items completed for a story, then the story is considered "groomed" or ready for consideration in a sprint.Until then the stories aren't complete enough for your planning sessions. This may be one reason why you are seeing people wanting to spend several days on them during each sprint. And they may actually need to spend several days during the course of each sprint working on story grooming -- just not all at once at the beginning of your sprint!
     
    Hint: The product owner doesn't have to wait for the start of a sprint to do their part of story grooming. In fact you should have 2-3 sprints worth of stories groomed before you go into a Sprint planning session so you have plenty of stories to choose from. Story complexity sessions should be limited to 1-2 hours after the other 2 items are complete.
     
    Once you have this backlog of groomed stories, then you can talk about how many points (vs. stories) the team can take on in a particular Sprint. As I'm sure you already know, not all stories are created equal. Some will be much more difficult to do than others. And you may decide a story is harder/easier after you dive into it. Having this backlog of groomed stories should help things out a bit I'm thinking, and help you move everyone from "how many stories can we do" to "how many points can we do" in a sprint which I'm sure is what you are already trying to do.
     
    Finally, usually within 2-3 sprints you will figure out how many points the team can take on in any given sprint. ( I'm preaching to the choir at this point...) One caveat though -- do not let your management try to compare number of points across teams. The number of points any team can do per sprint (aka team velocity) is totally unique to them.
     
     Hope this helps. Have a super week!