Jeff Patton’s talk at agile 2009 about Pragmatic Personas is quite interesting. I’ve seen talks about personas way back at agile 2007 already, but, at that time, I found them quite “bulky” to use. In pragmatic personas I see more value.
Click to continue…
After following Dan’s tutorial on installing munin on your servers, you already get the benefits of munin’s default plugins. You have graphs showing your CPU, RAM, I/O, as well as MySQL, Exim, and quite some other stats. But most of the time you run some additional software which you also want to montior.
Click to continue…
When we start optimizing our processes, it happens quite often that we only optimize our area of influence instead of addressing the whole process of creating customer value. When we’re responsible for a software development or an operations team, we tend to optimize the process of our team. We adapt agile practices and our teams performance seems to skyrocket. But even if we’re that successful, it might do more harm than good. We might flood the QA team with features, which they have to sign off, creating overload on their end. Or our operations environment might be the greatest part of our organization, but there are no new features or necessary bug fixes arriving for deployment.
Too often people complain that to become agile they need to start using iterations, fancy story points and time boxes even though it simply does not fit the way they work.
But, that’s not true. Agile is much simpler than that. And much harder. In essence, agile is about fast feedback. But the feedback needs to be relevant.
Click to continue…
Automatically setting up and maintaining my servers is a must for me. Only if everything I install and configure on a server is scripted I’m sure I know what’s there and that it stays that way. Having automated infrastructure enables me to schedule a critical setup change at 3 am and be on the safe side even though my brain might already be half asleep. After having written a ton of capistrano tasks (and creating a mess with it), looking into puppet and chef, writing my own tool (carpet), my colleague finally gave Sprinkle a try.
Click to continue…
If you want to get things done, focus is the key. Single piece flow (focusing on only one task at a time) might be too extreme, but limiting your work to your capacity is mandatory. No matter whether we’re talking about a team, an organization or about your personal productivity.
Click to continue…
I will continue my course about agile methodologies at the University of Augsburg with both a Scrum and a Lean project simulation. The Scrum simulation will introduce the students to concepts like User Stories, Backlog, Iteration, etc.
After doing lots of Gantt Charts, Use Case Diagrams etc. in the waterfall simulation, it’s time now to break down the requirements into small and independent User Stories. The User Stories shall then be sorted by priority: The Backlog comes into existence.
Click to continue…
Matthias and I started this blog over a year ago because we had first-hand experiences with the rift between developers and sysadmins. We knew this was a lose-lose situation not only for those directly involved, but the companies they were working for as well. We’ve described many real-life examples of how to overcome this rift, but were never sure how these ideas were resonating out there with our fellow colleagues. How many developers had moved into the operations realm? How many sysadmins knuckled down and wrote end-user code in a pinch?
Click to continue…
The first simulation in my course about agile methodologies will be waterfall style. Here’s how I plan to do it.
Before we go into the details of the waterfall simulation, I want the whole group (around 20-30 people) to come up with requirements for the product to build: an online office suite (maybe the most boring but also the most well known thing in the world). I plan to gather the requirements upfront because I do not want to burden the first simulation with this additional task – all simulations should start mostly from the same starting point. The team will be free to document the requirements as they like, no special format required (those special formats of recording and managing requirements will be part of the individual simulations). When we have a good set of requirements, we’ll start with the first project waterfall style.
Click to continue…
Agile methodology builds on the concept of iterations – time boxes – in which you create a piece of working software. Each iteration starts with a planning meeting where the team takes stories from the backlog and commits to the sprint goal. If you use a tool like Pivotal Tracker, you even get emergent iterations – the tool automatically cuts your backlog into iterations based on your team’s velocity.
Click to continue…
