Archive for the ‘Agile’ Category
Alternatives to Basecamp for more functionality
Tuesday, April 20th, 2010 by stephThe power of goals
Tuesday, November 17th, 2009 by steph
I used to have a very good way of managing my own time.
I had a list in my head and every now and again I’d remember stuff that I needed to do and I’d do it. Don’t get me wrong, I always did my PM documentation but just didn’t manage my own tasks in the same way.
This made me a pretty good intuitive project manager and thankfully my memory was good enough to pull it off.
Then I got older…a little more forgetful..and I managed bigger projects… and more people. I progressed to writing my lists down.
My lists got too big, and my working life got too mobile so I progressed to using outlook. DOH - that didn’t work. I ended up just staring at a screen of red tasks. My husband swears by Outlook (so each to their own) but for me it just didn’t have enough manual dexterity to it.
Meanwhile, my personal life was getting pretty complicated. Moving cities, buying a house etc so I started keeping lists on my phone and tasks in my diary.
Then I started managing my own business…
I thought I had things fairly under control until one day I realised I had a list on my phone, a list on basecamp, a list on tactile AND a list on each of my many desks and…it went on!
I didn’t want to go so far as to say that lists didn’t work for me anymore but clearly something had to give.
It helped when I got my own desk. Just one solitary desk to manage, on which I could keep just one solitary piece of paper with one master list of tasks.
Then I realised one day that I had 45 tasks on my list and they were all due that day. So the nice concise list I had started with, was now spilling from a page of A4 onto post-its that stuck to my coffee cup and threatened to escape down the table-leg out into the corridor.
“This isn’t very Agile” I thought to myself.
Whilst pondering on Agile, I started to wonder why I had spent a great many years trying to manage my own time in a completely different way to the way in which I managed my team’s.
And then it hit me; I had been managing my own time in a soul destroying way. There was a chunk of time allocated (9 - 6pm) and I had to fill it with “stuff”. I was making endless lists that could have gone on forever (and what’s more), even if I came to the end of the list, if it wasn’t 6pm yet - I WOULD JUST KEEP GOING!
Like an Agile team with lots of Sprint Tasks but no Sprint Goal, I was just aimlessly churning out “stuff” until the customer (i.e. me) said that they were satisfied. As I’m quite hard to please, this would sometimes end up being 4am in the morning. So in fact, I wasn’t very good at time-boxing either!
Finally, I realised the power of goals. Every day, just one - and if that goal got done, my day was done too.
So now I have a goal in my head and every now and again I remember stuff that I need to do to complete my goal and I just do it. I cross it off my considerably smaller written list which was created not as a memory aid, but purely for the purpose of being able to triumphantly scribble it out.
I used to have a very good way of managing my own time. Now I don’t manage time at all… just my own expectations.
I don’t proport to be the author of this idea of concentrating on goals rather than tasks and have almost certainly nicked it from Harvard. Three rather than one is certainly more ambitious and I find 2/3 often occurs. But if you (like me) don’t like failure, imagine the other two as back up “should have” goals 
Read more here
Agile in the Enterprise
Tuesday, October 6th, 2009 by cindyedmondsThere is an exciting shift in the Project Management world from focussing on teams to moving our attention to the Enterprise. I am very excited about this because over time as a Project Manager you realise that you can arm yourself with skills, knowledge, certification and techniques and you can lead your teams and equip them with knowledge and freedom to work in a focussed and directed way and still hit obstacles that invariably lead back to the organisation. Both Prince2 and Agile practitioners are starting to think about how to address the organisational issues and how to scale methodologies to the enterprise.
Last week at Valtech’s Agile Edge conference Al Goerner gave a terrific key note session on Adapting Agile to the Enterprise. In explaining the maturing of Agile practice he outlined the two generations of Agile:
1st Generation - Agile for the team
- Emphasising the Human Factors in development
- Emphasising Empowerment-to-a-goal
- A Gaggle of Gurus
- Naive Agile and Faux Agile
2nd Generation - Agile for the Enterprise
- Emphasising Risk Management
- Emphasising Backlog Management
- Emphasising Visibility and Accountability
- Emphasising the Whole Solution Value Stream
The 2nd Generation of Agile practices really resonates with me and I’m sure resonates with any Project Manager who has worked in large organisations. How many of us have wrangled with the 1st Generation ‘Gaggle of Gurus’? I certainly have!
Managing risk and providing visibility and accountability is so important in the enterprise and I’m completely inspired by Al Goerner’s presentation on exactly these issues. His most important point was that Agile doesn’t mean not focussing on these things and it doesn’t mean not producing documentation and certain other claims made by the 1st Generation-ers. The key thing is to only do things that have a point, that will be read, and not just as a formality or because they’re ‘required’.
Beam me up Scotty!
Scrummaster reflections
Tuesday, September 15th, 2009 by cindyedmondsI am now a Certified Scrummaster which means I have done the formal Scrum training and have certified that I lead the team using the official and recommended techniques. During the course I was happy to see that we at Magic Milestones already follow the Scrum techniques closely so there was not a lot of new ground to cover. However, hearing the other course attendees describe their workplace environments, usually in the context of explaining why Scrum isn’t working so well for them, I was a little bit disheartened about certain trends. Because Scrum teams are self-organising and the teams make their own decisions there is a bit of a trend to not use Project Managers in the Scrummaster role and to use developers or tech leads instead. The main role of the Scrummaster is to remove impediments and obstacles to the team’s progress. In order to do this the Scrummaster needs to be empowered in the organisation so that they can suggest the changes that are often required in order for goals to be met. This is where I see the huge value in having a professional Project Manager in that role - someone who is experienced in working with top management and implementing organisational change to support the project and who is empowered to do so. If a developer or tech lead is empowered and experienced in these things then having them as Scrummasters is all well and good but if they are not, and if they are not interested in that element of the role, then the situation can arise where Scrum is shoe-horned into less than ideal situations.
By empowering teams to be self-organising and making their own decisions you can certainly get great software results and team cohesion. However, you can’t always get a team that is capable of changing processes outside their immediate area, such as integration testing or other third party dependencies, so that timelines are shortened and goals met. In the Scrummaster course there was a lot of discussion about when is a task ‘done’. It seems that in a lot of organisations it is hard to get to ‘done’ due to dependencies on other teams such as a QA team or processes that create delays before a developer can say that their task is ‘done’. An empowered and experienced Scrummaster should be able to suggest and implement process changes to remove these delays and integrate with other teams or dependencies. If the Scrummaster role is being performed, on a rotating basis, by developers or tech leads rather than managers with experience in process change then I think the team will struggle to get to ‘done’. Becoming self-organising doesn’t remove the need for management.
10 pointers for Agile Design
Thursday, April 2nd, 2009 by admin- User research is imperative but not ad infinitum - set limits
- Interation with development should be informal but large scale changes need to be managed via the iterative planning session (e.g. Sprint Planning etc)
- Use artefacts to communicate with clients and the team
- Use paper prototypes to find out what works for users
- Too many designers spoil the user experience
- Documentation should be based on what is required at that particular moment
- Don’t invest tons of time in mock up early on as it may have to be undone later
- Track design somehow but be aware that using similar techniques to engineering tracking can lead to issues as design often comes together late in the day resulting in a mammouth burn on the last day - meanwhile the project manager is already pulling his/her hair out. Understand the differences between engineering and design tasks
- Don’t be afraid to show the customer stuff early - just set the expectations and ensure that they don’t cling to designs before these are solidified.
- Have courage, be transparent and remember that everyone is headed toward the same objective of a successful project
Recent Comments