Tag: Agile

Yeah, We’re an “Agile” Shop

Everybody Has Gone “Agile”

If you’re a software developer that’s done interviews in the past few years, then you already know that every software development shop has gone agile. Gone are the days of waterfall software development! Developers have learned that waterfall software development is the root of all evil, and the only way to be successful is to be agile. You need to be able to adapt quickly and do standups. You need to put story point estimates on your user stories. You need retrospectives… And agility! And… more buzz words! Yes! Synergy! In the cloud! You need it!

Okay, so why the sarcasm? Every single software development team is touting that they’re following the principles of agile software development, but almost no team truly is. Is it a problem if they aren’t actually following agile principles? Absolutely not, if they’re working effectively to deliver quality software. That’s not for me to say at all. I think the problem is that people are getting confused about “being agile”, but there’s nothing necessarily wrong with how they’re operating if it works for them.

Maybe We’re Not So “Agile”

I work at Magnet Forensics, and for a long time now, I’ve been saying “yeah, we’re an agile shop”. But you know what? I don’t think we are. I also don’t think that’s a problem. I think our software development process is best defined by “continuous improvement”. That’s right. I think we’re a “Continuous Improvement” shop. Our team has identified the things we think work well for us in how we develop software, and we experiment to improve on things that we think aren’t working well. I’m actually happy that we operate that way instead of operating by a set of guidelines that may or may not work for us.

So, why aren’t we agile? When I look at the Agile Manifesto, I feel like there’s a few things we actually don’t do, and we don’t even worry about them. We don’t necessarily have business people working with developers daily through things, for example. Our delivery cycles are much longer than a couple of weeks most of the time. Sometimes people on our teams don’t communicate best face-to-face. I mean, just because we’re not focusing on those things isn’t necessarily proof that we aren’t agile, but I truly don’t think we’re trying to embody all of the components that make up agile.

As I stated previously, I do think that we try to focus on continuous improvement above all else, and I’m absolutely content with that. I think that if over time we continued our retrospectives and our team ended up operating closer to a traditional waterfall process then it would be the better thing for our team. Why? Because we make incremental changes for our team in an attempt to keep improving. Switching to waterfall is a bit of a contrived example, but I definitely stand by it. Another example might be that maybe working with business people daily isn’t actually effective for our team. I don’t know, to be honest, because we’re currently tweaking other parts of our development process to improve them. Maybe we’ll get around to worrying about that at some other point.

I do know that the way we operate, we’re always trying to improve. Whether or not we get better sprint to sprint is for the retrospective to surface for us, but if we took a step back, at least we can try a different path when we try to take our next step forward.

So, We Don’t Need To Be Agile?

I think my only point of writing this post was to get this across: If you’re not actually an agile software development shop, then don’t call yourself that. There’s absolutely nothing wrong with not living and breathing agile. Maybe you’re a software shop that’s transitioning into Agile. Maybe you’re moving away from Agile. Maybe you have no parts of your software development process that are agile. Who’s to say that because you’re not 100% agile your setup is bad?

I can’t advocate that agile software development is the absolute best thing for all software development teams. I personally like to think that it’s a great way to develop software, but… I don’t know your team. I don’t know your codebase. I don’t know your products, services, or clients. How the heck could I tell you the best way to go make your software?

Again, there’s nothing wrong with not being 100% agile, but we should try to be honest with ourselves. Find what works for your team. Find out how you can effectively deliver quality software.


Continuous Improvement – One on One Tweaks (Pt. 2)

Continuous Improvement - One on One Tweaks (Pt. 2)

Continuing With Continuous Improvement

I wrote about continuous improvement before and how I’ve been trying to tie that into my leadership role through changes to my one on one process. To recap, at our organization we try to roll continuous improvement into most things that we do. We’re well aware that we’re not going to get things perfect the first time, so as long as we have a process in place to learn, reflect, and adapt, then we can make changes to better our situation. It’s something that’s ongoing and it doesn’t really have an end. So long as your organization is growing and changing over time, or the environment in which your organization is changing over time, having continuous improvement baked into your culture is key to success.

Previously, I mentioned that at Magnet Forensics I hold regular one on ones with my team members. I made a tweak to them that included summarizing notes before holding the one on ones and saw a great improvement. I felt that for now this would be a positive change that I’d like to continue on with. I’ll keep reflecting on whether or not this makes sense over time.

What’s next, then?

Recognition

Recognition is something that I think is fundamental to keeping people engaged, but it looks different for everyone. When I comment on things or share things on social media, I often reflect on how recognition is incredibly important. It’s been a goal of mine to try and do a better job at recognizing my team members for the hard work they’re always putting in.

That was my next hack for continuous improvement. How could I leverage my one on one time to do a better job at recognition? Well, if recognizing my team for things they do is high on my priority list, then it should fall high on the one on one discussion list. The first thing, actually.

So now that I create a summary of topics to go over in our one on ones, I reflect on what my team members say they work on and I toss in other stuff they may not have mentioned. Did they have big accomplishments in our sprint? Did they have things outside of work? Did they have tweaks they suggested for the team to try? Accomplish goals they set for themselves? I try to gather that information and comment on a couple of things at the start of our one on ones now.

I want the team to know that their hard work and their success does not go unnoticed and that they should all keep working to the best of their abilities.

Results?

I’ve only been doing this recently, so I can’t quite say that I’ve noticed big differences. In my opinion, the team has been entering a solid groove over the past few months but it’s hard for me to say whether or not these one on one changes had any impact. I like to think that they did. I’ve heard from several people that they’re really happy with where the team is at.

Has this brought about anything negative? Were there any cons to rolling out this change? I’d say no, not at all. It’s no extra effort for me to reflect on what accomplishments each team member has add. I mean, I’m not writing out lengthy documentation on each accomplishment, but I jot down a couple of points on what I want to call out. I think if anything, that quick exercise has been really positive for myself, if not for the other team member.

So, in the end, I think this small tweak has been a positive change for me in terms of doing a better job of recognizing the team. I also hope that the team has a better understanding that myself and others do see their hard work and efforts.

Keep on it, Team Magnet!


Continuous Improvement – One on One Tweaks

Continuous Improvement - One on One Tweaks

Continuous Improvement – Baby Steps!

Our development team at Magnet Forensics focuses a lot on continuous improvement. It’s one of the things baked into a retrospective often performed in agile software shops. It’s all about acknowledging that no system or process is going to be perfect and that as your landscape changes, a lot of other things will too.

The concept of continuous improvement isn’t limited to just the software we make or the processes we put in place for doing so. You can apply it to anything that’s repeated over time where you can measure positive and negative changes. I figured it was time to apply it to my leadership practices.

The One on One

I lead a team of software developers at Magnet, but I’m not the boss of any of them. They’re all equally my peers and we’re all working toward a common goal. One of my responsibilities is to meet with my team regularly to touch base with them. What are things they’ve been working on? What concerns do they have with the current state of things? What’s going well for them? What sort of goals are they setting?

The one on ones that we have setup are just another version of continuous improvement. It’s up to me to help empower the team to drive that continuous improvement, so I need to facilitate them wherever I can. Often this isn’t a case of “okay, I’ll do that for you” but a “yes, I encourage you to proceed with that” type of scenario. The next time we meet up, I check in to see if they were able to make headway with the goals they had set up and we try to change things up if they’ve hit roadblocks.

No Change, No Improvement

I had been taking the same approach to one-on-ones for a while. I decided it was time for a change. If it didn’t work, it’s okay… I could always try something else. I had a good baseline to measure from, so I felt comfortable trying something different.

One on ones often consisted of my team members handing me a sheet of past actions, concerns, and status of goals before we’d jump into a quick 20 minute meeting together. I’d go over the sheet with them and we’d add in any missing areas and solidify goals for next time. But I wanted a change here. How helpful can I be if I get this sheet as we go into the room together?

I started asking to get these sheets ahead of time and started paraphrasing the whole sheet into a few bullet points. A small and simple change. But what impact did this have?

Most one on ones went from maxing out 20 minutes to only taking around 10 minutes to cover the most important topics. Additionally, it felt like we could really deep dive on topics because I was prepared with some sort of background questions or information to help progress through roadblocks. Myself and my team member could blast through the important pieces of information and then at the end, if I’d check to make sure there’s nothing we’d missed going over. If I had accidentally omitted something, we’d have almost another 10 minutes to at least start discussing it.

Trade Off?

I have an engineering background, so for me it’s all about pros and cons. What was the trade-off for doing this?

The first thing is that initially it seemed like I was asking for the sheets super early. Maybe it still feels like I’m asking for them early. I try to get them by the weekend before the week where I start scheduling one on ones, so sometimes it feels like people had less than a month to fill them out. Is it a problem really? Maybe not. Maybe it just means there’s less stuff to try and cram into there. I think the benefit of being able to go into the meeting with more information on my end can make it more productive.

The second thing is that since I paraphrase the sheet, I might miss something that my team member wanted to go over. However, because the time is used so much more effectively, we’re often able to cover anything  that was missed with time to spare. I think there’s enough trust in the team for them to know that if I miss something that it’s not because I wanted to dodge a question or topic.

I think the positive changes this brought about have certainly outweighed the drawbacks. I think I’ll make this a permanent part of my one on one setup… Until continuous improvement suggests I should try something new!


Recognition: One of Team Magnet’s Masterminds

Recognition: One of Team Magnet's Masterminds (Image by http://www.sxc.hu/)

Background

At Magnet Forensics, I lead an awesome team of people with the mission of creating forensics software to help investigators around the world solve crimes. We’re stacked with incredible people–and not only on the team I’m on, but company-wide. We do a great job of recognizing our achievements as an organization and as a team, but also on an individual level. If someone has gone above and beyond, we don’t keep that a secret.

I’ve been trying to make more of a conscious effort to recognize the people I work with, especially in ways that are unique to my own style. I think recognizing people in person is important, but you also need to consider your setting. Sometimes recognition in a public forum isn’t actually appreciated or isn’t nearly as effective as appreciating in a one-on-one setting. I find even for myself that I get uncomfortable when being recognized in a public setting.

With that said, I wanted to recognize an individual I work with without shining too much of a spotlight directly her. Thank you, Christine, for all of your hard work.

Broken Retrospectives

At Magnet, we try to adhere to some agile philosophies.  It lets us pivot pretty quickly to customer needs–which keeps them quite happy–and still lets us deliver rock solid software. We develop in short cycles called “sprints” and at the end of every sprint we have a retrospective to look back at what worked well and what didn’t. That way in the next sprint we can make improvements. Keep the good stuff, drop the broken stuff and try out a thing or two that’s new. This is excellent for continuous improvement unless…

They don’t work.

We would run our retrospectives religiously, but it seemed like nobody really wanted to be there. It was a seemingly forced meeting where I felt a lot of the time I was trying to stir up conversation. By the end of the meeting, just about everyone would have chimed in, but there weren’t a lot of ideas being generated. It was long, boring, and didn’t accomplish any of the goals we wanted it to. Thus, our development cycles stayed basically the same for a while. They worked and they didn’t appear to be broken enough that people wanted to see change.

Things remained the same until I received some input from Christine. When Christine read an article on LinkedIn called I Like, I Wish, I Wonder, she thought it might have some positive carry-over to our development process. If Christine thought that it might spark a change in our retrospectives, that was more change than I was hearing from the team in general (including myself, to be fair). So I decided we’d give it a shot.

Annnd we haven’t looked back since.

I won’t go too in-depth on how I Like, I Wish, I Wonder has rocked our retrospective world because I want to save that for a separate write-up. The point is that it did, and it’s all thanks to Christine for digging it up for us. We’ve started to completely overhaul different aspects of our development process now that retrospectives are effective. I really started to realize just how big of an impact it had when I was explaining some of the development process changes to our CEO. I remember thinking “Wow… If we wouldn’t have switched our retrospective process, we’d be nowhere near as efficient”.

So, thank you for the retrospective idea, Christine. For anyone else looking to flip retrospectives around, try out the I Like, I Wish, I Wonder scheme.

Personalities

I can imagine a lot of people in the development world don’t think too much about personalities. I know I didn’t. Sure, everyone is different. Everyone has their own effective ways of communicating, things they like, things they don’t like, and optimal situations for working. I get it. Now let me go do my work and you go do your work. In an ideal world, you just assume everyone can figure out everyone else that they’re working with, and things will just be fine. Except things are never ideal, and it never hurts to put in a bit more effort to make sure you can get your team up to speed.

So we tried something out. I worked with my HR manager (read: communicated a potential scenario for our development team, let her run free with her awesome creative ideas, and then helped her where she needed it) to roll out a Myers-Briggs personality test for a small sub-team of our development team. If you aren’t familiar with the tests or the concept, check out the link and read up on it! We figured it would be best to try this kind of thing out on a small part of the team to see if they would find value in it, and if so, we’d try the whole team.

After we rolled out the Myers-Briggs results with the small team, the benefits were immediately noticeable. We didn’t even have to leave the room before seeing the benefits. We knew there was some potential here, so we were already excited to try it out with the rest of the team. With everyone being aware of how other individuals may act and react when communicating and working, it makes a big difference in how particular scenarios are approached.

Thank you, Christine, for making differences in personality something to be cognizant of and then supporting our roll-out of Myers-Briggs. For anyone reading this that manages a team or is part of one… Consider the personality types of the people you work with. Maybe you don’t need a formalized Myers-Briggs plan, but it’s worth raising awareness of it.

Thank You, Christine

Christine, you’ve made a lot of great contributions to the team and I’d like to thank you for them. Our development processes have been able to greatly improve thanks to your initial suggestion. I’m sure we would have adapted over time, but your suggested tweaks have certainly acted as a catalyst. Your furthered support with the personality type analysis and subsequent rollout was also greatly appreciated. You were able to participate in our mini-experiment and offered great feedback to turn it into a success for the entire team.

Thank you. I’m looking forward to what this year will bring!


Quality & Agility in Software: Session With Paul Carvalho

Quality & Agility in Software: Session With Paul Carvalho

Quality And Agility

Last week, at Magnet Forensics we were fortunate enough to have a very talented quality expert come in and talk to us. Paul Carvalho was able to bring a great deal of information, perspective, and activities to our development team that truly proved to be an eye opener. We were all extremely excited to get to sit down and hear what Paul had to say.

There’s lots to read about Paul over at his STAQS site, but I’ll re-iterate some of it here. Paul has held many roles when it comes to software development. He’s been a developer, a manager, a tech support person, and part of quality assurance. He certainly has a full perspective on software development. Coming from a science background, he does a great job of explaining why things are a certain way or why you’ll expect results given some conditions. This made understanding his approach to quality and software much easier for me to get a handle on.

It felt like we covered so much, but I want to provide a high level of the take away points that really stuck out for me.

Quality: What Is It?

Paul started us off by getting us to describe what quality means. In the end, we arrived at something that provides value (where value is actually defined) to an audience (again, where audience is actually something that’s defined). So what does that mean? Quality is dependent on who and what you’re talking about, so it’s important that when you’re trying to deliver quality that you are all aligned on what exactly quality will mean.

To illustrate his point, Paul had us perform an exercise where we really only used one method of communicating some information to our partner. The result of the activity proved that even when sitting right beside your partner, you can lose a ton of information in how you communicate. So having tickets written up or having a one way communication channel is almost guaranteed to cause some misunderstanding when it comes to expectations. Part of the solution? Converse. Actually have the person describe back to you what you said. This way, you both start to hone in on what your expectations are. It was a cool exercise, and it definitely proved his point.

Perspective

We also discussed perspective a lot in our session with Paul. He had examples where simply altering your (physical) view point on something would cause you to describe something completely different. From there, we drew parallels into our software development process. There’s the old “but it builds on my machine” scenario that mirrors this really well. Paul really wanted to drive home that product owners, developers, and testers all have different perspectives on things so we need to get on the same page to ensure we can deliver quality.

Paul also asked us what seemed to be a really simple question, which for a few of us meant that it actually had to be a loaded question underneath the obvious. By showing us something on the TV in our board room, he asked us if what was being shown was a particular object. The easy answer sounded like “well, duh, yes”, but he was driving home a huge point on perspective. We weren’t looking at the object, we were looking at a TV showing a digital rendering of a piece of artwork that depicted some object. The answer was kind of abstract, but it was really cool to have that conversation about what you’re really looking at.

Awesome Agile Activity Alliteration

As a team lead, there was one activity I found absolutely awesome. I’m hoping everyone got the same take away form it that I did. Paul had us work as one big group to perform some activity. The goal was to circulate as many balls through every individual in the group as we could in two minutes. There were a few rules that I won’t bother explaining, so it wasn’t necessarily that easy.

Quality & Agility in Software: Session With Paul Carvalho (Image by http://www.sxc.hu/)

Having 15 people shouting and debating in the first planning portion made things pretty tough, but we came up with a workable solution. Paul made us estimate how many balls we thought we could get through, and we felt so poorly about our design that we said only four. We tried it out, and managed to get about 20. Awesome!

We were told to do another iteration, and he gave us another mini planning session. Again, the shouting and mayhem ensued, but we wanted to tweak our first approach. We finally organized, and when we tried it out, we doubled our initial throughput. We were onto something. The next planning session, the shouting was a little less, and we added a few more tweaks. We noticed the following problems from before:

  • We were moving too fast, so balls were dropping.
  • We were only moving one ball between people at a time.
  • Our throughput was nearing the limit of how many balls we had.
  • Our counting was extremely poor.

Solutions? Slow down. Move two balls instead of one, which should be easy if we’re going slower. Recirculate the balls instead of putting them back in the container. Dedicate one person to counting that wasn’t me (the person who would either inject more balls or get them from the end to recirculate). We shattered our previous record, nearly doubling it again. Next planning was similar. We addressed some minor pain points and decided to go for a whopping four balls at once. We added another 25 to our throughput, so we were sitting around 100.

At this point we realized we were nearing the potential maximum throughput for this design and given the time restrictions for planning, we couldn’t generate much to improve upon. We debated a completely different approach for a bit, and realized it was going to be unrealistic–but this added to the takeaway.

So, with that said, what WAS the takeaway from this activity and why did I like it so much?

  • The activity is a direct parallel to our sprints. The balls are the features we’d be developing.
  • The planning process was hectic. Everyone was involved and generated great ideas, but it took a select few “leaders” to actually pull triggers. Otherwise, nobody would agree on ANY of the great ideas we heard.
  • Dropping a ball was equivalent to a problem sneaking through or something not getting done. In terms of quality, this was like a customer seeing a bug. The more people that touched it likely meant that the bug would be smaller or have less of an impact. A cool little quality parallel.
  • We need to be continuously improving. We should leverage our retrospectives to improve our process. It’s important that we keep experimenting with our process to see if it can be improved.
  • There will be a point where we think we can’t improve anymore with our current process. If we’re not happy with throughput, it may require a completely different approach.

Summary

The whole team thought having Paul in was great. We have a ton of things to take back to the drawing board to use and try to improve our processes. I think it’s safe to say any one of us would recommend consulting from Paul. His insights are excellent, he conveys his thoughts clearly, and he has activities that are so incredibly aligned to the points he’s trying to get across.

I’m looking forward to using Paul’s techniques for improving the quality in our software and the processes we use to develop. Thanks again, Paul.

Links


Intrapreneurship – Guest Blog by Tayfun Uzun

Intrapreneurship - Guest Blog by Tayfun Uzun (Photo by www.sxc.hu)

Last week I mentioned a colleague of mine, Tayfun Uzun, had a little surprise. He’s put together a great write up on intrapreneurship and what it means to be an intrapreneur.

The importance of Intrapreneurship

Innovation is the life-blood of any organization; we have all heard it and one way or another understand it. Actually, let me rephrase that. Revenue is the life-blood of any organization, but innovation begets revenue. One big movement in large companies is the idea of intraprenuership, the act of behaving like an entrepreneur within an established organization. Intrapreneurship is baked into your culture–it starts from your first hires in a start-up and needs to persist as you grow. It is not something that you can take a two day course and learn, much like entrepreneurship.

Why do you need intrapreneurship? Well, innovation is what sells. Companies have come and gone because they were stuck in the status quo, not innovating and thus becoming stale. The status quo is boring and demotivating. While these companies make great case studies, they do little to motivate the people involved. Intrapreneurship instills the drive, creativity and urgency into your employees. You can either have one person be an innovator or you can make the entire organization live and breathe innovation.

So, how do you foster an environment where your employees can feel comfortable being intrapreneurs? There are a few things I have found effective to get people out of their shell and try different things.

Be Agile

Following the agile model of iterative product development allows you to be able to test your innovations more frequently and get feedback quickly. This is a key component to intraprenuership. The waterfall methodology doesn’t allow time to tweak ideas and prototypes often resulting on those projects being scrapped for high priority planned projects. With agile you can time-box your innovation, forcing the intraprenuers to feel the same pressure an entrepreneur would feel when building products. A good way to do this is having regularly scheduled hack-a-thons where employees can work on their own innovations for a set period of time.

Encourage and Lead by Example

If you are the founder this one is easier than you think. As a leader, people look up to you and imitate you. As the founder, it is not uncommon for your employees to want to be entrepreneurial like you. Just listen to their ideas. No. Actually listen. I get it–you are the visionary, the entrepreneur–but there is value in hearing and seeing the prototypes being developed by intrapreneurs. Imagine injecting your entrepreneurial spirit into each one of your employees, because that is what you are doing by listening and providing them the platform to innovate.

By providing the means for your employees to become intrapreneurs, you are indirectly improving their day-to-day planned work. It allows them to view what they may consider mundane tasks in a different light and become solution-based thinkers. I often think of innovation as a prize–I am glad to do the grunt work as long as I get to innovate frequently–and in turn this affects how motivated I am as an employee.

Don’t Bet The Farm

If you are gaining traction, don’t pivot. Slowly start empowering the intrapreneurs to be product visionaries too. A good rule, (over)used in agile, is the 80/20 rule. In your next project, try to have 20% innovation driven by the intrapreneurs in your organization, while 80% are planned features. A good way to do this is to take out one or two features that you have planned for a sprint/release, and let the intrapreneurs research and build something. This is a good way to foster creative thinking and innovation with little risk.

Tayfun Uzun was one of the first software engineers at Magnet Forensics and currently is the Product Development Manager, responsible for the Software Engineering team.


  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress