The daily standup meeting or scrum meeting presents the team with a regular opportunity to synchronize development activities with the iteration plan and to check and reflect on the progress of the team’s commitments towards the iteration goal. As a forum for communication and feedback, the team members co-ordinate their work and make a commitment to the team about what they aim to achieve in the day. They also identify any difficulties and obstacles to progress. The meeting is not intended to generate solutions nor remove obstacles.
One of the first hurdle that any projects comes across is ability to gel as a team to deliver projects. Specifically when the teams are adopting agile where the key focus is around people and teams. The shift in ways of working from traditional to lean methods puts the teams at great discomfort to start with and often determines if you are able to adopt to agile or not.
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.
Scrum Master is responsible to ensure that the Scrum framework is established along with Scrum Values, practices and rules enacted and enforced. The ScrumMaster is the driving force behind all of the Scrum practices. Thus most of the ScrumMaster’s responsibilities fall entirely within the purview of Scrum itself. The role in itself might sound very light weight from the outside but single handedly holds the fort, sheilds the team from external interruptions and provides a tremendous value add to product owners helping them organize the business and product roadmap.
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.
One of the great threats to the functioning of a team is a set of 5 dysfunctions that could plague the team. These dysfunctions build upon one another and could negatively affect the team in such a way that the team would eventually crumble.