Author: adam

You know the team is too large when…

If you’re a startup, then your organisation is the team. If you’re in a larger enterprise, your team can start small: maybe even just with you! but if you are even modestly successful, you’re going to have to grow the team. In fact, beyond the craziness of early stage startups, mostly you have to grow the team in order to be successful. But as you grow, you run the risk of getting too large. How large is too large?

Read More

“That’s Not Agile!”

We implemented all the relevant principles in the Agile Manifesto, and serviced the Manifesto values. We didn’t contravene or ignore anything defined in the manifesto. Even more, it was proving itself in the early stages: the team bound together quickly just through the discussion and planning on how we were going to do it. We had designed a nice mini agile methodology but the development department wouldn’t play ball: they said “that’s not agile!”

Read More

Thanksgiving for IT Teams: Lock in your team’s achievements!

Scrum and Agile Guru Mike Cohn wrote in his weekly Agile Tips email that we should mark the moment to focus on what our teams have achieved. Triggered by the bigtime Thanksgiving celebration in the USofA, Mike wrote how we often struggle to recognise the past good work done because we are focused on how much we can improve in the future.  He said: “There are literally hundreds of ways in which a team may have improved. Find a few and then share the good news with the team. Praise them. Thank them.” — Mike Cohn (Btw, you can subscribe to Mike Cohn’s emails here) The most important by-product of this is to make the achievements concrete. It would be great to make them persistent, but I’d settle for short-lived crystallisation into the real world. Why? Because it’s so easy for teams to forget their achievements and to gloss over their successes. In fact, the better the team, and the more outcome-focused the team is, the less they seem to celebrate; except perhaps some wry or sarcastic comments, a few obvious high-five’s and maybe an ‘Attitude Adjustment’ session at a pub. But this tends to disappear quickly and all that’s left is maybe a sore head and an expense claim to file. It’s as if the really good teams just have a higher standard of what is “superlative achievement”, or they...

Read More

Service Level Agreements define Unacceptable Behaviour

Service Level Agreements, or Service Levels defined in contracts, typically define maximum delays between certain events in the procedural interaction between two enterprises.   They are intended to create clarity and precision in the dealings between these two enterprises, and to balance the business priorities of the enterprises against the cost of implementing the support. A typical example is the time between a “customer” enterprise notifying a “supplier” enterprise of a problem, and the “supplier” enterprise responding to that notification. It is not uncommon to have several interactions defined in sequence, such as: notification of problem, administrative response, diagnosis, solution and long term fix.  The further into the future you look the less common are fixed timeframes and/or the range of timeframe becomes larger.  How can you guarantee a time to fix when you don’t know the problems that will be raised.  However, there are some cases where these are locked down. The SLA should define the longest time that is reasonably expected that the event should happen, before some degradation of performance begins to occur  the “customers” operations.  Such degradation may not (in most cases don’t) occur immediately, but the lead time towards that degradation has been consumed almost completely: there is no more wiggle room. But in practice, once these SLA’s have been established into the operational cycle, a strange thing often happens: one or both of the...

Read More

Subscribe to AdamOnProjects

Never miss out on anything.

Pin It on Pinterest