# BeforeReading
I just blog the training I participated, and record down what I experienced, observed, it doesn’t mean I support its opinion or suggestions. Because personally I believe software development should be managed in the way of Continuous Product Development, instead of short-term focused Project mode.
Well, a couple more words, Project Management is much more wide, and not specific for Software Project (e.g. a housing project, a build construction project), therefore the thoughts behind that doesn’t fits best. While Agile focus on software development more.
# Before Reading
Joined as observer in a 2 days training “Agile Development and Project Management” , delivered by IIL, the trainer is Wolfgang Wendl from Germany. He mentioned it’s his first time to China, and I think that’s the reason why he faced some problems during the training, since he didn’t know Chinese in training. Normally there will be English problems, especially if you have accent, and they wont tell you they didn’t understand. And so on.
In the opening part, he has a “Housekeeping Item”, which looks like a “Training Agreement”, talking about e.g. we don’t need computers, please mute your mobile phones, etc. There is one entry attracted my interests, it’s the “Emergency Exit”, even it is kind of unnecessary since we’re in our company’s building, but in general it’s very good, since the training may happen somewhere else, and it’s sweet to tell people how to exit in case of emergencies.
Below are the drawings he made regarding “Project”, “Project Management”, and the link of Project Management between “Classical” and “Agile” methods.
Once he explained the definition of several terms, “Practice ∈ Method ∈ Methodology ∈ Approach”, sounds reasonable, don’t know if it’s common accepted or not, I’m not a native English user. Needs further investigation.
I’m suspicious how he explained Scrum and XP.
He used the word “Done Done” that team should deliver “Done Done” features at the end of sprint,
while IMHO there is only “DONE” and Definition of Done.
For XP, check the photo. Curious about second-based Pair Programming, and hourly Code Integration.
My question is, would PP be too pressing, and Code Integration too less frequent?
When “Communication” was mentioned, Wolfgang illustrated by drawing it out as below.
While the sender sending messages to receiver, and receiver provides feedback.
There are different Culture, Education and Experience, which makes communication hard.
That is our Model of the World, and they’re different of course.
Communication is about increasing the overlapping part of sender and receiver.
We went to the Knowledge Areas of project management : Scope, Time, Cost, HR, Quality, Risk, Procurement, Communication, Integration. The project phases are Initiating, Planning, then Executing, and Monitoring, final one is closing.
Risk Management was not in the original course content, they adjusted based on our request, picked it up from their Project Management Fundamentals course. As written on the flipcharts, risk is an event which has possible impact, either positive or negative. Risk Management contains 4 activities, 1) plan first; 2) then identify them; 3) analyze the risk via a PI (should be Possible Impact) matrix; 4) Define the Response Strategies, which might be “Avoid”, “Accept”, "Mitigation”, "Transfer”.
He introduced several tools for this, e.g. SWOT or Critical Path analysis. For me, it’s funny that when he asked “anybody heard SWOT analysis before?”, nobody raised their hands or answered. For the Critical Path (or other names, my memory is bad…), I just don’t understanding why we complex our simple life by this. Didn’t get the idea of using ET / EF / LS / LF, and Float.
These 2 charts should be the drawings while he is explaining WBS (Work Breakdown Structure). And he embraced User Story technique into this WBS thinking, considering Epics as the first level deliverable, and User Stories as the second level work package, and then split them into tasks. When it comes to estimating, due to the famous “Padding”, estimations are not accurate or trustable, therefore you can use “Three Point Estimate”, one Optimistic estimation, one is Pessimistic, and the Most Likely one. Then you could use (O + P + 4 x ML) / 6 as the final estimation. My view is, playing with numbers doesn’t improve your estimates, and finally ensure you’re on time. And also, the uncertainty of estimates are mainly from the work itself, instead of trust issues. Even if there is such an Agile Project Manager, this kind of distrust behaviors will reinforce itself. E.g. PjM doesn’t trust teams’ estimates, and thought he must ask team to give 3 estimates, then the team will feel the PjM doesn’t trust them, then while bother giving trustable estimates?
The explanation on “Trust” as below, those characteristics look fine, but can not understand the formula “Trust = ( C + R + I ) / S”.
- C : Creditable
- R : Reliable
- I : Respect + Caring
- S : Self-Orientation
Here is his summary on differences between “Classical PM” and “Agile PM”. No Comments. Sounds reasonable if you read from a more PM angle, sounds nonsense if you read from Agile angle.
Finally, the most interested part “Stakeholder Management”, it’s actually given in the beginning as in the first module. Which is identifying different Stakeholders, clarify or access their interests and power, and then act. It’s exactly what my sales friend told me about sales, you have to figure out who can affect the deal, what’s their impacts, on technique decisions or business purchasing decisions, can they accelerate the sign of contact or you have to ensure they don’t slow you down.
