Week 6: Team structure

There are 3 important aspects to a productive work environment (employee satisfaction):
1 - The people
2 - The site
3 - The work

Each can be broken down further, but focussing on the people side of thing we have:
- organisation structure/hierarchy
- team structure

Drilling down further, we can break the team structure (the immediate team of usually 2-10 employees working on a single project) down to:
- size
- skill level of individuals
- experience of individuals
- knowledge level of individuals
- personality

Successful teams are usually small groups of employees who have a good understanding of each other. Knowing the individuals in your team is critical to the success of a team. Everyone knowing the strengths, weaknesses and nuances of each other person will have many benefits: planning, communication, productivity, cohesion, etc.

If everyone knows what everyone else is doing, it's easier for the individual to see how their work is contributing to the whole, which helps them to see "why" they're doing what they're doing as well as helping with the 3rd factor of employee satisfanction (above: 3 - the work).

Whether it's best to have a good mix of experienced & inexperienced employees working together is arguable. The same goes for skill and knowledge levels. Often there's not a choice one way or the other, you only have the personel infront of you to choose from (as a manager). However, these aspects do affect the overall successfullness of the team. It is important for the 'why' factor to have employees working not just in their own field. If there's a technical and logical side for instance, a technical-guru should be involved with the logic side of things (even if it's just through the logic-guru presenting a fortnightly summary of work done during a meeting), and vica-versa. This not only keeps everyone on the same page, but increases the knowledge level of all employees (again: factor 3 - the work).

And then there's the personalities. This is a wildcard, but I've witnessed 3 types of interaction.
1 - the team instantly gels and form solid relationships from the start.
2 - the team cannot get sorted and never really get on.
3 - some team members hit it off while one or two remain 'outsiders'.
4 - it takes a while for the team to gel, but given the right social environment and targetted encouragement they eventually form good working relationships.

The first is obviously beneficial. The second can be disasterous and result in the team being segregated, unwilling to work directly with one-another and each person going off and working on their own part in isolation. It's parculiar, but in my experience, the 3rd is the most productive. The dynamic is often that the 'outsider' becomes isolated and puts in a lot of work, which in turn puts pressure on the others to become more productive (good motivation). However, it's a delicate situation and carries the greatest risk of everything falling appart.

There are infinite variations on the 4th and it's probably the most common. But if the people are willing to work together and have a good attitude towards the success of the project, it can be just as effective as a 100% coherant team. However, it would probably not have the longevity of a team who is 100% coherant.


A good team dynamic, recognition of the team dynamic and appropriate proactive management of the team, can make the difference between a team who fall appart after or before one project is completed and a team who stay together for several years. It's a major part of each team member's life satisfaction and is regarded in many organisations as THE most important thing to focus on. Particularly large organisations.

Week 5: the agile why

It's not a concept that's bound to agile methodologies, but it is appropriate none-the-less. "Why am I doing this?" It's appropriate to agile because in an iterative process it's easier to get sidetracked. Detours, getting stuck on minor details, can potentially damage the timeline of a project.

More important than the time allocated and even the quality of the work is a consideration of the purpose of what you're doing in the context of the project. Is what you're doing working directly to achieve a goal?

A thoroughly planned out and managed team should have less trouble identifying work units on the critical path. Identifying those work units when you have your head buried in the software in the middle of an iteration is tricky. But if the answer to "why am I doing this?" points directly to a requirement then doing that work now is likely to be justified.

This is particularly useful in our BSE team project. With 12 people and loose management & requirements, it's important to frequently ask why you're spending time working on your work unit and how much time you're allocating to it in the context of the iteraction. Without asking the 'why' question, it's all too easy to put your head down and later discover that you've wasted a day's work and you're no closer to the goal.

Week 4: Week too?

Skipped a couple of weeks, but it's just a change in standard.

Doomed from the start
It became apparent at this week's lecture that we (BSE final year project) got is all wrong from the start. Heading out to visit the client with a massive knowledge gap and little requirements gathering experience was a recipe for disaster. I think we knew it at the time, but we let it slide.

12 people all smiling and nodding, taking some sort of notes from vague scribbles to word-for-word exhaustive dictation. We didn't have a plan for the session, we were not prepared and we got out of it exactly what we put into it. We went in without structure and a mind to catergorise, watch for 'pain points', problem/solution space or form/function. Our client didn't know what they wanted but they knew more about it than us, so we were in no position to direct the meeting. Due to this, we followed their lead and that directed us away from a "develop this product for us" type development-based project to a "show us as much as you can about this stuff" kind of research/analysis project. Had we had more domain knowledge at that time, we could've directed them down the develop us a product path and right now we'd have a solid product to do exactly what they wanted in the first place instead of patching together 3 pieces of software to give them a seemingly hacked together product where the most intensive part will be making the GUI solid.

We had little practical training in (or agile methodologies for) requirements gathering. The first exposure to it was when Raj walked into our LSSD lecture and started logically plotting out requirements into categories and laying out a plan for structuring the way you think about requirements. But the damage had been done and we were on a colision course for the situation we're in now. Had we got that initial step right, it may well've got us a solid development project, which would in turn have made the entire project far more interesting and negated some of the motivation problems within the team.

Shows the impact of one early step in the Software Development Life Cycle on a project. Especially as it was related to client interaction.

Week 01: the beginning

That aside, it's time to talk Software Engineering practices and Agile methodologies. Since this is the first week, I'll start with what I now know of both topics and maybe what I hope to learn throughout the semester.

Software Engineering is the thorough process of taking a project from conception -> delivery -> the end of its useful life. It's about professionalism and all that bollocks, but more importantly using appropriate methods to produce and maintain the software to the satisfaction of the client (time, cost, scope, with as many -ities as you can think of). There's a certain amount of quality expected from Software Engineering, including working documentation, final documentation and the product itself. An appreciation of risk (and effective risk management) is also key to the success of a project.

Throughout this subject, I hope to polish up on some techniques. But more importantly, I'm hoping it will change the way I think. Adding structure to my thought patterns and how my brain gets around certain aspects (such as requirements, design, risk, etc.) has improved immensely this year. During LSSD, several things stuck in my mind which I have since used to good effect:
- Vision vs Pain (the motivation of the client)
- Knowledge, Skill & Technology (three key categories of risk)
- People... Communication (communication in several contexts is the #1 risk in most projects I've been involved in)

Agile processes I know little about. But it sounds like fun. It is very mindful of risk, keeps a close eye on progress in relation to the overall goal and relies very heavily upon communication. Without communication, everything goes to hell.

Lamentations of an undergrad

It's not a new realisation, but the idea that our course has been fairly poorly structured is becoming more and more apparent. In a 5 year Software Engineering course, it's criminal that we are only properly learning how to get our heads around a problem and structure our thinking to devise a proper solution. Instead of Software Project Management, we would've got a lot more out of something like LSSD then. That would open the door for Agile 1 and Agile 2 in final year. I fear that at the end of semester, I'll still feel there's more to be learnt from Raj and Jean-Guy. Then I think back to the wasted time with Professional Issues in IT and Software Project Management and lament the fact that I couldn't squeeze in Games Programming.