Initially you might find that not everyone seems to be as enthusiastic about Agile as you . Most people don’t understand this new system that’s why they fear it. People are typically fearful of change anyway so a new system when they’ve been pretty comfortable with one that they had been using for a while might seem discerning at first. But when this happens don’t try to present Agile as if it’s the only way to go about things.
Moving forward with the perfect team
Now that you have your core team in place sort out the Agile techniques, concepts and frames that apply most to the task at hand. Take requests from the team about the requirements that will help them perform their tasks most effectively. The employee might need to get more funding or outsourcing for this to get done but just make it happen.
You might want to even hold a teaching session on which Agile techniques your team will adopt. This ensures everyone from employees to investors are all on board
Turning the table
After the team has understood the Agile concepts it will adopt it is time to take a good long look at each other and see what is best for the company, what they need from you as a team leader and what they need from each other as partners working with each other. Chart out some WOWS (Ways of Working) constructed by the team itself to boost confidence and that each person has a say in what the final product will be. Just make a few short 8 to 10 pointers .
The backlog is where you keep and note down all that is expected from a given project. At this point obviously it is is too early to know the problems one could run into or the design flaws that might make a particular attribute unusable so Backlogs are created. Backlogs are simply log lines of small statements that in Agile are called “user stories” In Agile there is no such thing as something ‘being compulsory’. This is because the smart people that made the agile manifesto decided that having something as compulsory would cause the project to run over budget and past schedule.
• Stories will get altered, tweaked, or detected altogether. Think of your story as a thing that’s always morphing into something more useful.
• Dont write stories locked away, by yourself in seclusion. Bring your stakeholders on board, bring your team-members up to speed with what you are thinking over
• Stories can be updated at any point during the life of a project bu definitely avoid changes during development stage,
• Try to always write from the perspective of a user or persona. The persona will be a mental representation of the user you are trying to create the solution for. it’s a good practice to think along these lines from the get-go
• To validate the quality of a good User Story use the INVEST model
• Keep the trickier, more complex stories towards the tope of your backlog. Then you wont be dealing with these tricky problems weeks before the product release
Road maps, prioritization and release planning
We’re almost at the end of our blog series on Agile. Next time around we’ll be knowing more about those terms written up there and why they are needed to make an agile project successful.