This week we have done the ProjectDirectors.org Expert Talk on Agile Project Management with Jonathan Goldstein, Director of Shared Platform Product Management at Merkle:
Please, share your comments on the topics covered.
Don’t forget to Subscribe, to receive our next articles and interviews.
• Business/Systems Analysis
• Risk Management
• Transformation and Change Management
• Process Re-engineering
• PMO Management
• Software Engineering
• SDLC Management
• Management of Distributed Teams
• Quality Management
• IT Governance
• Financial Modeling and Analysis
• Exceptional Communication Skills
• Release and Configuration Management
• Technology Strategy
• Business Continuity and Disaster Recovery
• Critical Thinking, Analysis and Design.
Here you can read the interview:
Q: Can you tell us a little bit about yourself?
At Merkle I have the great fortune of being a core part of the Real Time Data Services team and we are chartered to provide best in class customer database integration solutions that are served up a central service to the enterprise. Our solution centers mainly on big data services. Last year we ran almost 100B rows of data through our core services and will exceed this by 50B rows in the next year based on current trends and forecasts.
Q: So it sounds like you are largely product focused, how does this align with Agile project management practices?
Agile methods and practices are used at a Product level to ensure that we stay closely aligned with business priorities and make sure our product roadmaps reflect the direction our business leaders require in order remain competitive in the market. Agile usage of Task ranking and close communication with business sponsors enable us to align our our roadmaps and sprint contracts with key business priorities. And, because of the frequency of communication required by Agile methods, we are able allow business to drive technology instead of the other way around.
Program Management wise, we have divided our unit into two main focus areas: Engineered Services and Product Enablement. Engineered Services are activities that are aligned to onboarding new customers onto our platforms. Product Enablement on the other hand are activities that are focused on plowing continuous innovation into our platforms to ensure they remain relevant and enable the business to outperform its objectives. Again, the business drives the task definition here. We have input at a detail view, but a macro view, they are advising us on where we need to focus our innovation and onboarding efforts.
With the priorities set at a Product and Program level, project management becomes simply the act of aligning the WBS task definition with the right sprint, the right resource and the right time in the sprint to ensure we hit our targets and enable our customers to meet theirs. As a central system service provider, our customers are really the project teams who are aligning their project plans with our capacity and capabilities to meet their clients’ objectives. It’s a delicate balancning act that without a framework like Agile in place, it would be unwieldy effort.
Q: So tell us a little bit about a day in the life now?
A: My day starts out with reviewing our daily burndowns to make sure we are on track. There is a still a bit of gentle reminding to our team members to make sure their tickets are reflecting reality, but for the most part everyone does a great job of keeping their tickets up to date.
Next, it’s time for the morning scrum. These are simple, 15 min max meetings designed to convey status but not drag on. We have an Engineered Services call and a Product Enablement call – a scrum of scrums, if you will. The results of these are published on our internal Wiki and enables my manager to brief his executives quickly with what we are focused on. We do open up time to huddle deeper into Post-Scrum topics that require us to strategize in greater detail.
Meetings should be limited to only those tasks that have been prioritized. Meaning, if you are meeting for something that doesn’t help you finish your prioritized objectives, then you should be questioning why you are attending at all, if not declining the meeting entirely. It’s brute force, admittedly, but it sends the message to the enterprise that we have a process we must follow.
At the end of the Sprint we run a quick 30 min retrospective:
- What is going well?
- What should we stop doing?
- What should we start doing?
We also review the objectives that were established at the beginning of the sprint and take stock of where we have iterated to.
We strive to finish each sprint with something demonstrable – whether it’s code, wireframes or ideas. If it added value to our products, then we make a point to show it to our sponsors. This also give us an opportunity to shine the limelight on one of our team members.
As Scrum Master, we package this up and prepare a sponsor presentation for the Sprint Review meeting.
Q: So what benefits have you seen after implementing this unique blend of Agile?
A: The benefits have been manifold:
1. Our Associates. First and foremost my management and I view our associates as the critical to success. When they are not happy, productivity goes down, recidivism goes up. Before, we implemented this system, there was a virtual ton of context switching based on who was screaming the loudest. Now, only the prioritized projects get to scream at us and frankly, because of our methodology…there’s really not a lot of screaming anymore. Our clients have become acclimated with our process. If they have gripes now, it’s more pointedly at our business executives who are setting the priority of our queue. The balance that this has returned to our associates lives is immeasurable. And the impact it has made on the work environment is equally immeasurable.
2. Our Client Teams. As mentioned above, because there was no formal process, our client teams were free to influence and cajole and try to upset the sense of priority. Now, the system is clearly defined and we believe that this has made their life more predictable as well. They understand that if their tasks are not prioritized, it simply isn’t going to get done and they equally understand that it is not in their best interest to try to shortcut the process.
Q: What solutions have you aligned in your PMO? A: We use Atlassian’s JIRA bug tracking to capture all of our sprint tasks and metrics. Our daily burndowns are captured out of JIRA. If the ticket isn’t in JIRA, then the activity never happened. And, if the ticket is in JIRA, but wasn’t prioritized for the sprint, then you will have some explaining to do.
We also use another product from Atlassian called Confluence to capture our daily scrum notes, fast collaboration on documentation, etc. Confluence is the method in which we emphasize working code over comprehensive documentation.
For project artifacts, we use an internal SharePoint site to capture information that needs to be easily shared and tracked through document versioning.
On the technology side, we use Subversion for our source code repository.
Q: Any key lessons learned from this journey that you can share with everyone? A: The key thing that comes to my mind is the truth in the Agile manifesto. As we have brought every line of the Agile manifesto to life in our group, we have seen dramatic turns in productivity, client satisfaction and most importantly associate satisfaction. It’s possible that there are better tools out there for us to use, but what has save us time and again is our process and our level of commitment to adhering to this process. For example, when someone requests a change now, we have a series of tasks in JIRA that are immediately created. The first of which is the Impact Assessment. We may still respond quickly, but the point is that change must be rigidly managed inside a sprint and if we are to change, then EVERYONE who is impacted by that change needs to know before we agree to it and/or the business approves the level of effort to complete the change. I would say this very act has saved us politically at least three times in the last month alone. Change is a constant and Agile is an awesome methodology by which to align both business and technology to respond quickly to change, but the movement must be in lock step. For, when it shifts out of alignment, bad things happen.
Second, I would say the thing that I am most a proponent of is the prioritization process. Recently, a group came to me with a due date I never agreed to on a project I knew nothing about and really couldn’t understand why I wasn’t dropping everything to help them out. Well, they didn’t exist to me. They hadn’t followed the onboarding process. They were coming at me mid-sprint. And their project wasn’t on anyone’s radar screen, most importantly our business sponsors. The prioritization process enable me to make sure my team didn’t spend unnecessary cycles and provided me the escalation path to make sure the issue was taken care of. Last I checked, the project will be prioritized accordingly for the NEXT sprint, and the process continues. It is hard for me to fall into the mindset of a bureaucrat, but on simple matters of ensuring that my team stays focused, I must say that this mindset must prevail.
In closing, Agile is awesome. But the box that Agile fits into must be equally awesome. When that happens, great feats are achieved, expectations are satisfied and good people with high value added are seen doing high value added activities for the company.