Posts Tagged ‘project management’

Project thinking pitfalls

Agile values tacit over explicit learning. It’s not that explicit learning isn’t valuable, it is; but it’s the tacit learning — where things become embedded and part of our nature — that is the most valuable.

If there were one piece of tacit knowledge that I wish I could transfer (think Vulcan mind meld) it would be the benefit of early and incremental delivery and the associated feedback loop.

Project Thinking PitfallsTo me the benefit of early feedback is obvious, and I can’t imagine any reason not to do it consistently, but sometimes even within my own organization I have to struggle against traditional project thinking, where some arbitrary date or perhaps some arbitrary list of features, often many iterations away is targeted as ‘the release’.

I don’t know where the roots of this type of thinking comes from, but they seem to be very deep and embedded. Difficult to change.

A couple of examples of the last year  made me sad. One recent and one early last year.

In the recent example a small team has been developing a web-based application. Pretty Scrummy. The Product Owner is good, providing the team with an ordered backlog of features to be implemented, and responding quickly to any questions that the team has. The team is solid, committing to and building a shippable product increment each Sprint and retrospecting to continue to improve. Sprint Reviews are also being held with the Product Owner and the feedback has been positive, but here is where things are also falling short of ideal. The Product Owner has this idea that once the features are completed that there will be “a release”. Actually the product has been shippable for quite a while, but instead of making it available and collecting feedback all along this entrenched project-style thinking of a ‘release’ has persisted. Most recently, as the remaining features for this “release” are being finalized the Product Owner has started talking about UI enhancements. Perhaps holding the “release” while these UI enhancements are being implemented. I call foul! The product isn’t yet being used by anyone outside of the development context and already we’re considering adding enhancements and therefore time and cost without any proven evidence that the product is valuable and will be used by the real end-users for the system. I’m actively coaching the Scrum Team around this now. I think I’m getting them course corrected, but I’m sad that my earlier attempts to influence and have the result of each Sprint released, used, and the related feedback collected and considered so that the Product Backlog could have been improved continuously didn’t result in action. How much waste has been generated? Perhaps none, but there is equal risk that the waste generated has been substantial.

The example from early this year is exactly the type of “project” that highlights just how wrong it is to not release early and often. Again overall the “project” was quite Scrummy. Product Owner with an ordered list of features and available to the team? Check. Great team with good agile engineering practices? Check. Potentially shippable product every Sprint? Nope. The work had been segmented, with our team responsible for creating a front-end while another team, in this case the clients own team, would be building the back-end services that the front-end would call. Not ideal, but often “projects” aren’t. We built our front-end, Sprint by Sprint. Each Sprint the team committed and achieved their commitment using mock-based services. But no back-end services were available, so there was no integration and things weren’t really “done”. There was good transparency. The client knew what was causing the undone work. Still they pressed forward. The originally planned front-end features were completed according to schedule. A successful “project”. How much waste was created? The front-end has never been used. All of the time, money, and a significant amount of team goodwill wasted. Very sad.

While there are contexts where project and release thinking make sense — think hardware for example — in a modern software delivery context it is seldom the case, and holding on to legacy project-style thinking results in plenty of waste.

Are you guilty of project thinking? Is clinging to the familiar creating waste in your organization?

I’ll continue to challenge myself, my organization, and our clients to be open minded in our thinking and approach to achieving business value. I challenge my readers to do the same.

Tips of Executing an Oracle BI Project in Multi-Shore Team

Happy families are all alike; every unhappy family is unhappy in its own way.

— By Leo Tolstoy Read the rest of this post »

Manage an integration project in control (Part 2 – Suggestions / Discussion)

In the previous post, we talked about some major challenges we experienced in an integration project. In this post, I will share some suggestions on how to solve these problems. I also bring the discussion about using “Agile” or “Check Point Control” in integration project plan.

Based on the previous post, it becomes natural that below items are important for managing an integration project in control:

1. Remove dependency on single integration environment

2. Manage cross team dependencies

3. Avoid vague integration design

4. Adapt to changes

5. Plan properly

Let’s discuss them one by one.

Read the rest of this post »

Manage an integration project in control (Part 1 – Problems)

It is exciting to see so many integration projects pop up in our offshore global delivery center (China GDC).  As we know, most integration projects are very often challenging. Since I have worked as the offshore team lead in a mulit-shore integration project, I would like to share what I learned with you.

First, I’d like to list several problems the team faced in the early phase of the project.  – I think they might be typical for many integration projects.

Read the rest of this post »

Creating bugs vs. finding bugs?

In one of my Scrum projects there was an interesting conversation between my testing team and the development team:

  • Tester A: “Look at that bug; it’s pretty straightforward that the functionality doesn’t match our test case. Why can’t somebody do a quick smoke test before checking in the code?”
  • Developer A: “Well, yes I agree that’s a bug. We just ran out of time – the schedule is tough for us, we did those most important verifications before we checked the code in; we made sure all Unit Tests passed, we made sure that the build is solid, and we wrote as many automated test scripts as possible but we didn’t have enough time to cover that functionality. It’s great that the testing team found that bug, we can fix it later.”
  • Tester B (Test Lead): “But that costs a lot, we spent a whole day to manually execute all the functional test cases and found at least 5 obvious bugs. They could be identified even without looking at the test cases. Now we need another day for regression test after your team gets them fixed.”
  • Developer B (Develop Lead): “But that’s the reality, isn’t it? It’s normal to have bugs. We cannot avoid delivering bugs together with the code. That’s why we have a testing team.”

Read the rest of this post »

How much effort should be spent communicating with an offshore team?

Currently more and more projects are multi-shore in a lot of big companies. Clients always ask us one question: How much effort needs to be spent to communicate with offshore teams if we work with one. It is one concern from clients that they need to spend more time to communicate with offshore team and usually they do not want to communicate with an offshore team directly.

So the question is how much effort should really be spent communication with offshore teams?

Basing on my experience, communication with an offshore team will not be much different from communicating with your onshore team if you have a good communication plan at the beginning of the project and implement your communication using some useful tools according to plan during the project. We already finished half a year’s project which has one US lead from client side to communicate with our team directly. And the following lists the best practices from my previous project on how to communicate with our US client directly and more smoothly.

Read the rest of this post »

Agile is mainstream according to Forrester

Interesting article in CIO magazine a few months back about a Forrester report that found 35% of IT professionals describe their process as ‘Agile’ and 46% that say they are at least Agile in spirit.

I think this meshes up well with what I’ve seen in the industry. In my job, I get to talk to lots of different clients across a wide range of industries, technologies and locales throughout the US.

Interesting, the conversation though can sometimes go something like this…..

“What type of software development methodology do you use here?”

“We consider ourselves an Agile shop. Our iterations are 3 months long”

So a half-empty kind of person would sigh that they are probably only Agile in moniker, but I’m a half-full kind of guy.

Read the rest of this post »

No communication and its impact on multi-shore teams

The first type of No Communication is very simple: nada, none, no acknowledgment, and zero feedback. Here’s an example. Our project was at a critical juncture and we ran into a few important questions. I wrote an email message carefully explaining the issues and sent it to Joe, our lead BA and product owner. I even made sure I checked the “important” flag so my email will get the appropriate attention. That was 2 days ago, and still no response. I saw Joe when I walked past a meeting room this morning and he appeared to be very busy. I am sure it wasn’t anything personal since he actually exchanged greetings with me. I left him a voice mail but he had not returned. I finally staked out his office and got the answers I needed. What if I was working in a distributed team thousands of miles away? What if our time difference did not allow us to easily communicate in real time? What if…? It’s always a best practice to send back acknowledgment. Communicate even if the only message is that you will have to get back later with a full answer. Read the rest of this post »