Measure What MattersMunish Malik
schedule 1 year agoSold Out!
While working with Agile projects, tracking and showcasing the progress of the project is an integral component that is of special interest to the account managers, product/ project managers, product owners and business stakeholders. A typical Agile project would be working with estimates, story points, velocities, burn-up or burn-down charts.
I have witnessed numerous sprint reviews and showcases where the business is only waiting to see those few slides of the presentation where there is the "actual" red worm, running against the "planned" green worm, trying to catch-up. If the red worm is ahead, I have seen a smile on the faces of the stakeholders. If it matches the green one, there is a sigh of relief. And as a development team you should just pray that the poor red guy is not falling behind the green one, lest it might lead to a lot of questions starting with why, how, what etc.
There have also been times where there have been some unfortunate heated discussions that last forever on why did the team end up not claiming a few points that they had committed. What gets lost is what the team accomplished in the sprint that adds good value to the product. There have also been times where the estimates are being questioned by the product owner or account managers. If you are working in a distributed setup where the product owner is working out of a different country, the problem is even bigger.
Let us think about a scenario where the project gets completed on time, budget and scope. Majority (or all) of estimates were correct. However, when the product went live to the market it failed big time. What is the use of building such a product?
Are we focusing too much on numbers and points and overlooking the other important aspects of Agile software development such as producing software that delights the customers and looking for ways on how we can measure that? Are we measuring if we are creating a solid, robust and a scalable platform that is ready for future developments and enhancements? Are we measuring the outcomes of the time we are spending in the shoes of the people who will actually use the software?
The objective of this session is to promote the thinking of measuring what matters for your project. To measure the goals that your software development wants to achieve. I don't plan to showcase an exhaustive list of measurements that can solve all your problems, however, I instead want to highlight some samples that I have used in my projects with the help of my team, that helped us to measure things that add value to the business and development v/S simply creating burn down charts.
Majorly, I want to encourage the audience of this session think out of the box to identify what measurements will really matter for your projects. Perhaps from the eyes of the users and business and see what things if measured will add a lot more value than simply estimates, and will help in creating a valuable product that will truly delight the business and the users of the product.
Project Manager from HellMunish Malik
schedule 1 year agoSold Out!
A Project Manager plays multiple roles in the organization. He or she has a role towards the team, towards the project, towards the business stakeholders and towards the organization itself.
The days of traditional project management evangelizing the concepts of "Command & Control" are long gone. Especially with Agile software development, the focus is more and more on building self managed teams.
It is said that it is easy for a project manager to lose his or her mind :D. Especially if you are under constant pressures of reporting project financials, status reporting, managing your project staffing & recruitment, stakeholder management, distributed teams, risk management, project planning, inceptions, lift-offs, project governance and to top it all, leading a group of different psychological beings who may be responding differently in different situations. There is no one size fits all when it comes to working with human beings, and you have the onus to build a self managed team. Hence, probably it is more apt to call our breed as project leaders than managers, but let us leave that discussion to a different day.
So if you are a project manager and getting stressed due the above mentioned pressures, or if you are clinging to the past styles of project management or you like being "old school", you may not realize but you might have turned into a devil.
How to be sure? Well... this session will offer you a checklist to confirm how close you are to being a devil or already have become one.
Building Agility Brick by Brick : A report on how Agile was imbibed successfully in an traditional projectAmit Kumar Srivastava
schedule 1 year agoSold Out!
I will be presenting a case study/experience report of a developing and implementing Web based Content Management System where the website was to be rolled out in 29 countries, having different languages and fonts, different country specific business/legal rules and equal number of country specific business owners.
The project was planned and executed by me in iterative waterfall manner and met all the milestones and timelines with huge customer accolades. I followed traditional project management but unknowingly was adhering to the basic Agile Manifesto in all the project management practices that the project had adopted . Whether its giving importance to face to face or verbal communication , enabling collaboration and communication with client on daily basis, ensuring website is doing what is important to business whenever the demo happens, and following development practice so that change request which are critical to the business, are incorporated without following the traditional change management process.