All people working in an agile environment should reflect on the principles behind the agile manifesto from time to time. What do these principles really mean? What impact do they have for my daily business? Does my habit follow these principles? There's a nice exercise for agile teams to summarize each of the principles down to 3 or 4 words. An agile team needs to have a shared understanding of the principles and what they imply for the team's behaviour.
Any product team in today's world would want to deliver any or every feature right away and right now. Needless to say this not just puts pressure on the development teams but majority of times end up messing the entire hardwork they have done adopting agile to deliver continuous value. The natural course of action is to prioritize the product backlog in such a way that the value reaches the customer as quickly as possible and there is a commitment on minimum deliverable along with some others as should or could deliver kind of scope.
Have you come across a dilemma of what should the length of your sprint be? I guess his is a common question for almost all the teams adopting agile for the first time or some of teams who are struggling to get to a stable sprint length. We did have this issue too and could get to some interesting drivers that could be pointers to define the length.
Writing contracts is a key topic for the sales team getting involved in Agile projects. While traditional implementation had defined set of methods to write contracts, not much has been experimented within agile based implementation. In the projects applying traditional methodology, companies had zeroed down on two popular models that are:
Agile Planning is one of the first and biggest challenges that you will come across if you are intending to transition to agile. Senior Management within enterprise in my experience expect overnight results since we now have moved to agile mode of delivery from either not having a delivery model/principles or traditional models. Well does that sound familiar? Being involved in transitioning teams to agile off late, have come across some common patterns which i thought could be classified into 3 levels that all teams have to go through before any team can confidently say we are working in agile framework.
Have you ever gone through the emotions of transitioning a team who are deep rooted with traditional waterfall implementation to a lean, agile way to deliver projects? I am sure most of you did. The biggest challenge while I was going through this phase was understanding the dynamics and behaviour of Agile teams, what an agile team should be and how do I mould the team to be agile. Mike Cohn in his book "Agile Estimating & Planning" talks about what "Agile Teams" are. I did like the chapter while i read a year ago but only understood recently on what he meant while trying to move my project team from traditional waterfall and chaos to much more agile.
Software penetrates every pore of human existence. We look up the weather info over the web, giving up on outdoor thermometers. We’re driving to destinations with GPS navigator (forget paper maps with their G7 sections on page 59). We turn on RunKeeper when riding a bike to calculate the average speed and run and boast in Twitter. We’re using software every single day of our lives. It seems we’re hugging our dear gadgets a lot more than our loved ones.
So your company has decided to go agile. Congratulations! If you're a PM that is currently part of a PMO that is transitioning from a more traditional Waterfall methodology to an agile framework you may be wondering what you’ll be doing with all that extra time now that you don’t have to write anything down, what steps can you take to keep utter chaos from devouring those self-organizing teams, or how you will justify your role with the company now that your new PO is going to hold most of the discussion with the client and team around the product development and requirements. Are you feeling that your days are numbered now that the PM role, at face value, looks obsolete?
The agile mindset promotes “individuals and interactions over processes and tools … That is, while there is value in the items on the right, we value the items on the left more.” For those of us lucky enough to be in an organization that has recently transitioned from a more waterfall approach to an agile one, which is almost everyone, please leave me some feedback on how far teams should be allowed to self-organize.
Agile Philosophy has been embraced by many organizations as the way to go to deliver software faster, continuous and with an increased value. However there are many instances where organizations either struggle to find a right approach for a successful transition or are swamped with challenges and struggle to come out of them, falling back to traditional implementation. This article gives some direction in terms of key transition challenges and a view on transition approach should you wish to go agile.