Agile Development: Are fixed length iterations essential in Agile?
I’ve noticed that the vast majority of people assume that Agile = Scrum = fixed length Iterations but the agile manifesto doesn’t say anything about iterations or Scrum. What it does talk about is early and continuous delivery of value which could be achieved in other ways such as multiple overlapping iterations or continuous flows. So are iterations really essential for agile? Are continuous flows of value a better way? Have you done agile without iterations? If so how did you go?
actually what you defined in your question ‘multiple overlapping iterations or continuous flows’ is also known as Kanban, the other (gaining popularity) Agile development methodology. In Kanban you dont have ‘time box’ what I think is your ‘contention’ about Iteration. in Kanban you continue picking up tasks by priority and roll it out to production, how many can be in each lane is defined by the WIP (work in progress) Limit. The whole team targets to keep the ‘cycle time’ (average time taken to get tasks from backlog to production) within limit and improve on it, if there is a bottle neck every one collaborates to resolve it and get the flow back.
So yes, you can do Agile without Scrum and Time Boxed iteration. We have been practicing this in several of our projects at BlastAsia (product engineering service provider) and even our product http://Xamun.com is build initially in Scrum, then most of enhancement, debugging and new features are done in kanban style continuous flow. You can use the tools inside xamun if you like for both scrum and kanban.
Scrum: How do you connect user stories with each other?
Typical user stories are very small, less than 13 points. This gives you just enough room for instance to add an entity in the backend with CRUD & UI. Sometimes you need to have a followup on the story, but this never happens, because it’s not planned and people just forget. Is there a way to provide a longer term narrative that connects multiple user stories?
Lets go through the SCRUM Product Backlog development logic to make sense. Ideally we are suppose to start by writing down the requirements in Epic Story formats, to define the entire system as we see it at that stage. Probably even marking those needed for MVP (minimum viable product).
Once the backlog is done in epic format, we set priority of what come ahead and what comes later in the build stage. Then we start to degenerate the Epic stories to Coarse Grain, and then to Fine Grain (which you mentioned to be of size 13 or below).
In this whole chain of fine-graining we can use numbering system to keep relation between which fine-grain came from which Epic. This hopefully gives that relation/connect between stories you are seeking.
We developed our SaaS product Xamun.com to include Scrum and Kanban with this idea in mind, down the line we will apply filters to view how all the fine-grain are doing in respect to epic.
Agile Development: How do you get the most value out of a QA role in an agile development process?
I have started working on a greenfield project with a 5-man development team, which only formed fairly recently. We use agile practices to design and develop our software. One of the areas were we need to improve is (automated) testing. How can a QA person best help us with this?
in our experience, ATDD works very well with SCRUM. The Test Engineer helps define the user stories in FitNesse table formats at least 1 sprint in advance. The development team works to make the test pass thus exactly meeting the story completion criteria, and also enabling automated regression testing of the entire build as the work progresses.
Software Development Methodologies: What are best practices for building complex software little by little?
I think you are a winner by asking the right questions in the beginning. Project management, specially getting software done right has been my area of fascination and research over the years. I might be biased but i have two advice for your:
1. Agile: get yourself and your team comfortable with either SCRUM or Kanban (suggest SCRUM in the beginning). identify shippable (some thing you can release to users, either to use or test) component/increments not too large and get it out every month or 2.
2. use a good process management and collaboration tool, that also captures the collaboration and discussions between the team. We build products for our clients all over the world for last 12 years at BlastAsia, with about a 100 member team, and to help with our own needs and several others like us we developed Xamun you might find it useful (www.xamun.com)
How does design (interaction and visual) fit best into the Agile process?
Building the full front-end first, from
Paper concept to photoshop (using the color palette and design standards set earlier),
Reviewing it for UX factors, (link or buttons, location of elements, size)
Then comes conversion to html/html5/jquery/css/responsive design for mobile
Verifying the interaction in the working prototype for front-end (with mock data), can be used for customer discovery if needed at this stage
Usually few rounds of refinement and stabilisation, specially the drag-n-drop usability for desktop and mobile, intuitiveness etc.
Once the front end is totally pinned down, the rest of engineering kicks in, to build, test, integrate and stabilise. Of course all this using Agile development and Lean Startup principals.
This has worked best for us, compared to doing parallel UI/UX or after which effects the stability of the system greatly and takes longer. Depending on what stage you are (that is enough work for the developers to keep busy while the front end is being refined) and how you source your team (in-house, contractors, new hire), you might have to plan your deployment accordingly.
Agile Development: It’s possible to run scrum without a scrum master? In what scenarios?
the goal of scrum master is to make the team ‘self managed’, an ideal state where the Product Owner and the team are in sync with each other, in developing the product backlog, choosing the right sprint items and delivering a consistent velocity.
we believe Scrum Master is a role that Agile Project Manager plays, and once the scrum team and PO reaches a ‘self managed’ state, the Agile PM can drop or reduce his role as SM and focus on other needs under his main role or can even pick up another team.
Agile Development: Do the drawbacks of tracking velocity with story points outweigh the benefits?
I suppose what the author describes in the ‘stop using story points’ article is a possible miss-use of how story point system, but it also points to the core problem of their team, trust. Trust is one of the core factors of Agile, and once that is abused or lost, nothing will work, story point or any other process I guess. Makes me wonder if the problem was with story point, or the team and how they were managed.
The alternative suggested focuses on continuous flow and cycle time is all part of Kanban process, another useful agile framework, that we use too. However Kanban and Scrum have their own benefits depending on what stage the project is and team dynamics from our experience. If you are doing scrum, then there has to be time-box and measurements. May be too broadly defined but offhand the argument sounds like if the players are cheating about the score, lets remove counting the goals and monitoring time in soccer. Velocity is like the heart beat of the projects progress and you cant do velocity without story points.
Perhaps the problem was the intended use of story point in the organisation, I can only guess, but once you start attaching individuals evaluations etc with story point burn down such can happen. However used as originally intended, discussing the stories in the process of measuring it together as a team and then measuring it as responsible adults if we are making good progress or not cant be harmful at all, in my opinion.
Does anyone have experience using agile development with offshore developers?
We’ve used offshore developers for years, with varying degrees of success. Now, we’re moving to Agile. Anyone combined those?
we (at www.blastasia.com) have been doing Product Engineering work for our clients across the globe for over 10 years and we have been using Agile (SCRUM and Kanban) 100% since over last 5 years. We are a team of over 100 full time resources working for about 8 to 10 clients at any point in time.
Yes, you can do Agile with a remote team, just have to be ready for Agile yourself. We have different level of sharing of work for different clients, some have a full team in-house and they augment with our team practically for all areas of work, other extreme we have client, who don’t have a single technical person onboard and we are their entire technical team for every aspect of product engineering. But once the product is live and needs first level support, probably better to have that onshore, rather than remote for smaller products, bigger ones have successfully moved their entire technical support offshore (we dont do 1st level/call support)
Most of the time challenges comes from client not being ‘Agile ready’, specially if the client is not the end customer and signed a Fixed price contract and then trying to outsource the work to us. Outsourcing requires trust and commitment from both sides, and Agile adds a multiplier to it, transparency is key, and great communication makes it easy to navigate when you have trouble for what ever reason. Like Michael said, PO needs to put in some good time with the team, at least to get the ball rolling and reach a good level of common understanding and trust. We recommend our client PO to spend about 2 to 3 week every quarter if possible onsite with the team, in the first year of engagement, can go down to as needed there after.
We also came up with our SaaS product www.xamun.com to ease some of the challenges of distributed Agile teams to the extreme option of 100% virtual team managed online. Check it out if you get time.