The interview with Darryl Booker conducted by Mirosław Dąbrowski
What is the difference in project vs. product thinking?
It all depends on the perspective. Product thinking mindset focuses on “WHAT” needs to be developed; project thinking mindset considers “HOW” to deliver the product. Project thinking encourages innovative solution to be done on time according to Clients requirements, in ideal world beyond Clients expectations. Product thinking mostly should focus on product functionality for the end user, UX cases and optimized business benefits both for Client and Company.
Where Agile fits in between those two?
Agile works between and for both – either Product and Project – and works very nicely. Agile approach allows the product to be developed in small increments and with close cooperation with Client (through Product Owner role) thus making more improvements to “what” will be delivered along the way. We can say that “Project” is driven by requirements and quality is a kind of exam for it and “Product” is based on design and testing is the final exam of a solution.
Agile fosters a collaborative team environment that allows team members and customers to plan “how” the product will be delivered.
In Agile do we still manage requirements, needs and client’s wishes?
In an Agile project you absolutely need to manage requirements which are evoked from Client’s needs, wants, wishes or even dreams. Agile enable to accomplish Client’s requirements without having to use “heavy duty methodologies” and “extensive requirements documentation”. Most important thing which shouldn’t be forgotten is having customer reviews of the product – incrementally, it allows the agile team to improve the product through customer feedback and experiential knowledge.
That’s the thing which is lacking massively among the skills or talent of Agile team members – Client communication and feedback sessions. From my experience, I’ve met some Agile teams that do not need a Client – they keep on developing the solution for a… solution itself. We need to remember that 45% of all approved requirements are never actually being used – if Agile project team do not track requirements in a solution.
Is Project Manager a good candidate for a Product Owner?
Anyone can be a good candidate for being or becoming a Product Owner but needs to build up a skillset before it happens. From my consulting perspective, the challenge for most project managers is their prior experience and mindset. For example, PMs are used to working with people to do things and telling them what and when to have things completed, sometimes in a very directive way. POs are focused on getting the right solution with all requirements tracked, letting the team determine how they work with backlog to accomplish the solution.
Fot. Marek DarnikowskiHow is the Product Owner role associated with business analysis?
The Product Owner role is associated with business analysis because one of the main focuses for business analysis is to determine “what” the challenge is for an organization and “what” solution can best fit the challenge and bring value to the organization. The PO’s heaviest duty is the whole solution and how requirements are reflected in it – let’s say the “wholeness” of delivering solution and especially focuses on bringing value.
How can we distinguish characteristics of good vs. bad characteristics requirement in Agile?
The basic elements of any good requirements are that they are justifiable and accepted by the business and bring value to the business. They are also feasible and can be delivered within project constraints. Requirements should also be measurable and testable – need to be shown and proved in delivery, traceable – most commonly forgotten – need to be shown both to-from and from-to path of delivery. They should also be documented – sad but true – online repository or real-time collaboration tools should help.
Can you use some of our techniques taken from traditional projects in Agile projects?
Yes, you need to use most of “same old” techniques from traditional projects and use them in Agile projects. Some of these are stakeholder analysis, project duration estimation techniques, risk identification and management, kick-off meeting best practice, leadership and communication management and lesson learned debriefs.
There are countless other techniques that can be used in Agile as well as traditional projects. One of the main points I make sure my clients understand about Agile is that – IT IS STILL A PROJECT – so you need to apply and utilize “same old, same old” project management techniques.
I would like to emphasize one message – PROJECT MANAGEMENT IS PROJECT MANAGEMENT – whether it is a traditional or agile project – one goal remains: to deliver value to the customer; the simple difference is in the methodology. So, if you like to be a good at Agile first you need to be at managing the projects.
Consider this, you and your friend want to eat sandwiches for lunch. You decide to go to the food court in the mall. You stop at McDonalds and order a sandwich – you tell them what you want on the sandwich, and you wait 5 minutes for it to be “delivered” – once you get your sandwich, you notice that it has more of what you are not fond of, and less of what you are fond of – you ask if they can make a change and give you more of this and less of that – you have to wait another 5 minutes, and hope that they make it “right” this time. Your friend goes to Subway and orders a sandwich. You and your friend are standing at the counter watching their sandwich being made; as it is being made, your friend asks for more of this and less of that, and then asks to add something not originally made on the sandwich (a change), no problem. You get what you want and you see it as it is being made.
In the end, both of you got what you were hoping for – a sandwich. One scenario required you to wait for the delivery and re-work, the other received what was asked and changed “on-the-fly”. This signifies the difference between traditional and agile project approaches – McDonald’s is traditional, Subway is agile.
A renowned international trainer, consultant and professional speaker, CEO of the consulting firm Booker Incorporated. In Poland he cooperates with Management Training & Development Center (MT&DC) as a senior trainer in the field of business analysis and project management. He has worked in the IT field since 1983.
He focuses on strategic business intelligence: CRM, PRM, ERP, knowledge management, and project management. He gained his knowledge and experience from years of working at IBM in various capacities, including: performance consulting, requirements gathering and analysis, skills analysis and assessment, application design and development, sales and marketing, and process and project management. He is an active member of IEEE, ACM, and PMI®.
Agile Coach, Scrum Master, Change Agent, trener, architekt, doradca w zakresie projektowania rozwiązań IT (specjalizacja JEE) oraz zarządzania projektami i programami. Anglojęzyczny międzynarodowy trener i wykładowca z wieloletnią praktyką, przeszkolonymi ponad 1500 osobami w Polsce i Europie. Miłośnik wiedzy praktycznej potwierdzonej ponad setką certyfikacji. Aktywnie promuje praktyki zwinne angażując się w konsorcjach Agile Consortium oraz DSDM Consortium. Tłumacz metodyk zwinnych oraz twórca narzędzi do badania poziomu zwinności projektów. Oficjalny ambasador holenderskiej fundacji ASL BiSL Foundation. Oficjalny ambasador metodyki OBASHI. Autor szeregu artykułów nt. zarządzania projektami. Twórca 50+ interaktywnych map myśli nt. zarządzania o popularności przekraczającej ponad 1.5 mln odwiedzin: www.miroslawdabrowski.com