Today we are talking with Gedas Mitkus, who has worked with a number of projects, big and small, and has recently founded a word of mouth marketing start-up PassAlong. Gedas shares his views on managing development projects and when agile is the right choice for a project – and when it is not.
You have a lot of experience in managing various IT projects, can you tell us a bit about yourself and what projects have you been involved in so far?
I have done a number of agile projects ranging in duration from 3 months to 3.5 years as technical lead/architect or as project manager with budgets from £20K to £5M. Most of projects were about launching new or building on top of existing web platforms, many with ongoing refactoring. The team sizes ranged from 3 to 40, with teams located in different time-zones. I have worked both with start-ups and established corporates.
What are the most typical problems or challenges you encounter in organizing the work?
As long as technical team is competent and with enough experience in technologies the product is being built on, I found the biggest challenge to be in aligning the Big 3 in a company – key business stakeholders, product, and technical teams. In many cases I found that inherent ambiguities in High level business requirements tend to translate into broad or unclear Product requirements, thus making technical development decisions and work challenging. This especially becomes a problem when due to business forces High level requirements change with ripple effects on Product and Technology development during a project. I saw lots of miscommunication arise within teams or even between team members when large portions of Product requirements change in midway. This can be further complicated when team members are not geographically collocated, work on different platforms, or team cultures vary.
Can you tell us what project management approaches did you use to solve these issues?
Different project management methodologies prescribe their own approaches. Waterfall and Agile have their own pluses and minuses. Agile is not a panacea, especially in big organizations, where multiple vendors and teams are involved in building complex projects. I think Agile is more appropriate for development of what is called Existing Evolving Assets in an organization – usually company’s main Product and closely related platforms, and usually built internally over a long period of time.
So you do not agree to the opinion that agile will help to deal with most project management problems?
It depends which perspective you take. Business stakeholders just want the Product built on time, on quality, and within agreed costs. Product Owners also often do not care which project management methodology is used as long they have flexibility to manage milestones of implemented features and respond to Product requirement clarifications or any technical obstacles that may impact the Product.
So it is up for Development team and Project managers to choose which PM approach to use. I think that Agile is more suitable when building new or evolving Product within a single co-located team of up to ten or twelve people, when Product vision or large portions may change or get deprioritized. However when Product must be built to specified scope, specified timelines, agreed budget and across multiple vendors with various contractual relationships, Agile is not suitable and will not address many problems. It is important to note that Agile is recent trend and if external or internal parties or their people have not used this methodology, it’s application would not solve, but would rather create problems.
Do you have any kind of personal preference for the way to work?
In my own startup internally we use Agile, but if external contractors or development companies are involved then we manage them using Waterfall, because Agile becomes too much of a micro-management from our side and would be too complex to structure contractually, unless contractor joins on time-and-materials basis.
A lot of CTOs and project managers indicate that communication within the team is one of the key issues for their teams. Do you also have this challenge?
I believe that 10% to 30% of a development budget is actually spent on communication and miscommunication between Product owners, Project managers, and Development team in New Product Development projects (as compared Implementation projects). So yes, it is hard to get people on the same page, and share vision for what they never built before.
In my own projects, I use a recent trend in development called Domain-driven development (DDD), although in much simplified form. Basically, my Product Owner knows the Domain Model Entities by heart, and so do developers and business people. That helps us use the same vocabulary and talk about the same things. This is critical in new product development, as domain vocabulary helps prevent miscommunication, and translate Product changes into a releasable Product quickly.
From all the tools that you are using, do you have any favorite ones?
In Agile projects in London and Austin, TX, I was involved in, the most popular is Atlassian’s Jira with Greenhopper add-on, then there is RallyDev and Pivotal Tracker. For Waterfall there is old good Microsoft Project, or Excel. To run small projects with up to 8-10 people or vendors, I personally prefer Spreadsheets in Google Docs or Excel, because they are simple and GDocs is even collaborative, though in both cases I need to write some formulas and do charts such as Burn-downs manually.
Do you have any advice to other CTOs and developers based on your experience?
Have established balance between the Product and Technology. Push back on Product people to have them clear Product roadmap and milestones, prioritized Product features, requirements structured to be consumed and not to be re-interpreted by development teams. Choose project management approach based on the Project, its requirements, development team skillset and technology vendor landscape. Make key decision such us platform, vendor, technology, architecture choices carefully with as much research and input on available options as possible, document those options as technical options papers (TOPS) as those decisions usually have great impact on Product, Project management and Business down the road.
Thank you very much!
