0

Something a little Different for the Chicago ALM User Group in October

by Angela 17. September 2014 15:54

So you may have noticed that the Chicago ALM User Group has been a little quiet this summer. Summer is always a tad slow and everyone would rather be out enjoying some time with the family, or maybe by heading up to the Wisconsin Dells for ThatConference like I did :)  Well, summer break is over and the Chicago ALM user group is back! We’ll be meeting in early October for something a little different.

I recently started working with a local firm who has come a long way in their quest for agility and a healthy corporate culture. They've accomplished some amazing positive changes in their use of ALM tooling, in their software delivery process, and most importantly in their corporate culture. Join us in October to hear their story, and maybe pick up some tips on how to make similar changes within your own teams.

Story-telling and panel discussion: Ever wonder how agile is supposed to work in real life, like how it’s described in the books? We did too and tried it out. We want tell our story, “There and Back Again”, a development team’s tale of how we are becoming agile including the thrills of victory and agonies of defeat, then open it up for a panel discussion.

Speaker Bios:

Daniel Porrey has 24 years’ experience in the IT industry with a range of skills from networking and hardware to software development. He has worked for several international based organizations striving to achieve high efficiency while driving the greatest levels of business value. Having been "classically" trained in IT as an Engineer, he has successfully completed numerous large scale projects under the waterfall methodology. With the need to gain even higher performance from his teams, the desire to hire and retain high performance talent, and the ability to deliver more automation, he converted his group to agile over the past several years with great success. In all endeavors, his primary focus has been on the quality of the delivered product.

Anthony Perkins has been part of developing software almost two decades. He has experienced being developer, software architect, and now manages a .Net application team. After working in the waterfall environment most of his career, Anthony is in the midst of transitioning to agile methodologies. Driving for continuous improvement, he looks for ways to improve the delivery of high quality software and overall development process.

Raja Tirumala Rao Guna  has over 9 years of software development experience in Microsoft.Net technologies.   He worked in different roles starting as developer and moving up the path as Dev lead, Tech Lead and Architect, though always a developer at heart.  For the past 2 years he been working on agile projects and using TFS to help on board his teams with Agile engineering practices.

Chris Steele has more than 14 years of professional software experience, and has been working with agile for over 9 years, with a heavy focus on Scrum. Working independently, with consulting agencies, or internally, in North America, Europe, Asia, and Australia has provided him with a wide range of experiences and a keen insight into the common problems and solutions that companies find when embracing agile, as well as how to present and sell it to clients ranging from the smallest to global enterprises. Having worked as a development team member, a ScrumMaster, a Product Owner, a resource manager, and an agile coach, in a variety of settings, Chris has had the opportunity to directly experience the day-to-day pulls and stresses inherent in each role, and in almost every organization type imaginable. Passionate about organizational change, and the benefits of agility, Chris also has experience as a speaker both locally and internationally.

 

Register now to secure a seat! http://chicagoalmug.org/

Tags:

Agile | ALM | Application Lifecycle Management | Collaboration | Microsoft | Process Methodology | Productivity | SDLC | Scrum | Team Foundation Server | TFS 2013 | TFS | Visual Studio 2013 | VS 2013 | development

0

The Many Templates of TFS

by Angela 23. January 2014 15:41

If you are a TFS user, especially if you are a TFS administrator, then you know that with every release of Team Foundation Server that there is a rev of the process templates. And if you work on a TFS server that has gone through a number of upgrades, it is possible that your Process Template Manager dialog will start to look like this:

image

So many choices!! Which one to choose? Ahhhhhhhhhhhhhhhhhhh… ::cough, cough:: Back in the early days, there were only 2 out of the box templates. I know, craziness! How did people survive with only Agile and CMMI? Well, there were always the custom templates that you could get off the internet, but that is a can of worms I am not opening in this post.  For now I want to focus solely on the OOB templates.

Over the years, the templates grew up, work item types got added, fields got renamed, workflows got streamlined, and in 2010 a new template was born. But who can remember which one came out with which version of TFS? Usually it’s not a big issue until you are working on a server with lots of legacy team projects, and you need to know what the original base template was. Pro tip, the TFS Team Project Manager can really help you to answer this question AND we found a bug that they recently fixed allowing you to compare 2013 templates all the way back to 2008 templates! Well, I started keeping track, and I get asked questions about this often enough that I figured I would just share my reference.

TFS Version CMMI Agile Scrum
2005 MSF for CMMI Process Improvement 4.0 MSF For Agile Software Development 4.0 N/A -- 3rd party
2008 MSF for CMMI Process Improvement 4.2 MSF For Agile Software Development 4.2 N/A -- 3rd party
2010 MSF for CMMI Process Improvement 5.0 MSF For Agile Software Development 5.0 Visual Studio Scrum 1.0
2012 MSF for CMMI Process Improvement 6.0 MSF For Agile Software Development 6.0 Visual Studio Scrum 2.0
2012.1 MSF for CMMI Process Improvement 6.1 MSF For Agile Software Development 6.1 Visual Studio Scrum 2.2
2012.2 MSF for CMMI Process Improvement 6.2 MSF For Agile Software Development 6.2 Visual Studio Scrum 2.2
2013 RC MSF for CMMI Process Improvement 7.0 MSF For Agile Software Development 7.0 Visual Studio Scrum 3.0
2013 RTM MSF for CMMI Process Improvement 2013 MSF For Agile Software Development 2013 Visual Studio Scrum 2013
2013 Update 2 MSF for CMMI Process Improvement 2013.2 MSF For Agile Software Development 2013.2 Visual Studio Scrum 2013.2

 

Now, I don’t *think* I have missed any versions here.  All of the major TFS releases, and some minor releases, have been covered.  But I’d love some feedback if you notice any minor versions that I may have missed. And I’ll come back and update this when TFS inevitably gets another update, and another rev of the templates :)

Tags:

Agile | Application Lifecycle Management | ALM | Scrum | Process Methodology | SDLC | Team Foundation Server | TFS | TFS 2008 | TFS 2010 | TFS 2012 | TFS 2013 | TFS Administration | TFS Power Tools | CMMI | Process Templates

0

Free Training When You’re Snowed In, What’s Not To Love

by Angela 2. January 2014 12:15

So it’s been snowing in Chicago, a LOT. I am in Oak Park, specifically, and holy moly did we ever get dumped on. Here, in case you think I’m being a big baby, this was my back deck at 7am this morning and it’s STILL snowing quite hard. There’s almost 10 inches of snow on those chairs right now, and there’s a pergola over them!

WP_20140102_07_54_12_Pro

Anyway, that’s not my point. My point is that I get to work from home this week, thank goodness, and ran across a great set of training classes on Microsoft Virtual Academy to fill some time. It’s free, yes FREE, and there are a LOT of technologies to choose from including ALM.  Although I’ll admit the ALM stuff is pretty light and scarce, and mostly focuses on 2012, so I’ll be nagging some folks about that soon. But there are also classes on Azure, HTML 5, even licensing!

Here is the current list of tools and technologies covered:

image

Clicking on Visual Studio I find a lot of great classes to get me up to speed on Windows development, HTML 5, you name it! What you see below is just the first few that came up, it’s a LONG list.

image

Best part is you can build up a nice little wish list since you may not have time to take everything today. So build a training plan, or several, and save the classes you like and take them at your own pace. Easy!  I already had one started from a while ago, but need to go back through and update it with some new classes, obviously :-P

image 

So dig in by starting here. And get some of those Microsoft certifications knocked out while you’re trapped in your house by snowmageddon.

0

Trying Something new with the ALM User Group in December

by Angela 3. December 2013 13:50

So it’s time again for the annual Christmas Edition of the ALM user group. Normally we do the normal “dinner and a movie” approach, maybe having a special guest speaker or some kind of presentation contest. This month I wanted to do something different.  In December, we’ll be doing an Open Spaces concept. So Open Spaces is sort of an “unconference” thing, where you enter into it with no formal agenda and let the attendees decide what is important and/or interesting to talk about. So think of a topic you’d be willing to lead, or a topic you would like someone else to lead. A few I’d be interested in talking about are transforming organizations to Agile, upgrading legacy systems to TFS 2013, and agile testing.  We will write them on a board, pick some locations for people to gather, and then you vote with your feet, bouncing around if need be.

As an added bonus, if you’ve been attending the ALM user group for a while, you know that December is “Angela cleans out her SWAG closet” month.  So I’ll have lots of fun giveaways including pens, stickers, mouse pads and LOTS of books. I’ll even have special prizes for people who lead an Open Spaces discussion during the meeting (think XBox/Kinect games, Arc mouse, T-Shirts).

So I hope to see you in Downers Grove next week.  I always enjoy our December meetings, and not just because of the cookies :)

Be sure to register soon so I can order the right amount of food!

 

 

Join Us Wednesday, December 11, 2013 from 6:30 PM to 9:00 PM
Location:  Microsoft-Downers Grove 3025 Highland Pkwy, Ste 300, Downers Grove

Speaker Bio: You, me, anyone who is interested in speaking!

Agenda:6:30pm dinner 7:00pm Open Spaces Kickoff

RSVP Now to Attend

0

Building Software, One Room at a Time

by Angela 30. November 2013 21:33

Comparing software development to “building a house” is one of those analogies that sets my teeth on edge. It oversimplifies everything that goes into designing and building a good product, and it also creates some unrealistic expectations in terms of estimation and effort, both for development and testing. I heard it yet again recently, and it just shocked me that it’s still being bandied about these days. C'mon, don’t act so shocked, you probably have said it yourself or heard it said at some point. I know I have, on both accounts. And you know what, it's OK, I’m not here to judge you. Unless you are still saying it, then I will judge you quite harshly :)

There was a time when this was far more true of an analogy than it is today. As someone whose original passion was "architecture", as in, creating blueprints for houses, it made a lot of sense.  Plans are good, and who doesn't like structure and rules? You see, there was a time when software was created by pouring over designs for the right "feel", sometimes for days or weeks to establish a solid foundation. Remember when SOA and OOP were the hot new things?  Before a single line of code was written we had UML diagrams and if we were really fancy stubbed out methods for the developers. And sure, when building a house every angle is inspected, measured and re-measured, the location and size of every supporting wall is verified, every window placement is compared to housing codes, all before a single piece of wood was sawn or hammer was swung. Then contractors are set loose with the specs to build the house according to a well laid out plans. Except what if by the time it was delivered, the homeowners didn’t want to actually live in the house they asked for in painful detail without some major rehab? The colors are all wrong, the yard is too small, the garage is too narrow, there aren’t enough bedrooms. Could you imagine?! In home construction, nobody sane would do that, and yet it happens all the time with software. Well, there you have it, the analogy is already somewhat blown. But there's more.

You know you've been on THAT project. You know the one - late, way over budget, customers are screaming that it isn't what they asked for even though you have signed requirements specs that say it is. Heck, even if you are just NOW getting into software development you're probably going to experience this still at some point. Particularly if you work someplace that is still stuck in a Project Plan driven mentality, a.k.a. "Waterfall" ::cue dramatic music::  Who just let out a little shudder? Now don't misunderstand, I'm not a hater, waterfall-based methodologies can work well in some scenarios, but generally even waterfall enthusiasts are not following a strictly traditional waterfall approach. And to be fair, even "real" waterfall, as I learned it back in college in the late 90's, dictated iterative practices. But often that little nugget gets lost in translation in favor of forever marching forward through a seemingly unending tunnel of quality gates, attempting to hit arbitrarily established milestones. So back to my original point. Building software is not just like building a house, or maybe the more correct way of conveying my thoughts is that building software SHOULD not be like building a house. And if it is at your company, I do not want to work there. Unless you're looking for me to facilitate an intervention of sorts. Let me explain...

Imagine you want to have a custom house built. And let's say you already know more or less what you want. Tudor style, 3 bedrooms, 2.5 bathrooms, eat-in kitchen, with a detached 2 car garage. Maybe you even have an existing blueprint because plenty of houses like that already exist, so why re-invent the wheel right? Work begins, and the house starts becoming real. But even after several weeks of work, while things may start to look like a solid shell of a structure, you cannot live in it.  Well, not legally anyway. There is probably no plumbing yet, certainly no electricity, perhaps the roof is not even yet in place. You also cannot decide you now want something more Spanish style, single storied and sprawling, with an attached garage and a courtyard garden in the center. Well, technically you COULD decide to do that but it would require MASSIVE structural rework, new permits, perhaps a different construction crew, and of course SIGNIFICANTLY more time and funding to complete. OK, so I suppose this is one parallel you can draw to software development, but again this is more of an issue in waterfall shops, particularly if you are already deep into development before someone realizes a much earlier decision was a poor one. Many thousands of man-hours will get wasted, people may lose their jobs, customers will be unhappy, and you likely will end up with a Spanish tiled, Tudor style home with a semi-attached 2 car garage that has a courtyard in the center of it. So with building a house, you will not realize the value of the product and be able to use it until the last finishing nails are hammered into the last room, and major feature change requests will almost always be unfeasible to honor even early on in the construction process without MASSIVE negative consequences. Do you want to build or pay for software that is built that way? I certainly don't. 

I don't see housing contractors ever building homes one fully functional room at a time, allowing the home owners to live in it long before it is finished. I do not see them redesigning the blue prints and only ordering enough supplies for each room about to be built to incorporate changing design trends, evolving safety codes, nor do I see them accommodating the ever-changing whims of the owners.  "Oh. You've decided you want an open floor plan instead of separate kitchen and dining rooms? No problem, we're just finishing the main bathroom and haven't even framed the rest of the first floor yet..." Yeah, no. I also do not see those contractors getting the homeowner's signoff on each finished component before moving on to the next one, incorporating feedback and change requests, continuing this iterative process until the house is complete. Maybe you're thinking, "well, we don't have the ability to do any of those things today when we design, code, test, and deliver software either". I'm sorry to hear that. We should talk, there's a 12 step program to help you, and you've already admitted you have a problem which is the first step to recovery. Well, there ISN'T a program, sadly, but I often joke that there *should* be.

Now this is an easier problem to solve in software. Software teams CAN be flexible, adapting to changing needs of end users. Software can be delivered in small, working, usable pieces to deliver value as soon as a few weeks after the project begins. And it doesn't have to cost more. It can actually cost FAR less if you do it right. This is part of the reason I am such a proponent of Agile and Scrum. But honestly that is another topic and this post is already long enough so we'll defer that conversation for now.

So here is one place where building a house and building software ARE remarkably similar.  Estimates. Regardless of what a contractor tells you, no one knows for sure exactly how long building a house (or software) will take. Sure we can ballpark it, but every job is different. People will sometimes push back and call that a copout consulting answer, but it's the truth, and I try not to make a habit of lying to the people paying me to work for them. And if you demand exact delivery dates, are unwilling to compromise on features (maybe the rotating shoe rack in the closet really isn't NECESSARY), and have immovable end dates, well, you may want to refer back to the 12-step program that I mentioned earlier. No one can account for bad weather, people getting sick, catastrophic hardware failures, or that the latest version of the .NET framework that was just released has added complexities that cause even the most experienced programmers to take 50% longer to get things done for a few weeks. Should you go so far as to expect the team to commit to dates, deliverables, AND cost - to the point they take a hit if any of those things slip - well, prepare yourself for a sandbag big enough to hold back a hurricane, or to have people eventually seek alternate employment. NO ONE wins. And yet these kinds of unrealistic expectations reoccur everywhere I turn in the tech world. Maybe someday more software teams will be able to hold stakeholders and end users accountable for the quality of requirements, and refuse to take on change requests after work has begun without serious concessions, seems logical and fair. Ahhh, dare to dream :)

So now can we stop comparing software to building houses? Please and thank you.

Tags:

Application Lifecycle Management | ALM | Agile | development | Process Methodology | Scrum | SDLC

0

Visual Studio 2013 Launch Event Coming to Chicago

by Angela 4. November 2013 15:18

So in case you’ve been living under a rock for the past few weeks, Microsoft released a new version of its Visual Studio ALM Tools including Team Foundation Server, Microsoft Test Manager, and Visual Studio. I know! Feels like 2012 just launched doesn’t it? With their new release cadence, if you blink you could miss a new version, or at least a few updates. It’s pretty amazing actually.

While there is an official BIG launch party happening on November 13th in NYC, you can also logon for the virtual launch that day if you can’t get away to the Big Apple on such short notice.  Although right now you don’t appear to be able to actually register for the virtual launch – DOH!  For now you can at least add it to your calendar, hopefully they will fix that soon.

I also just heard that there are also some smaller in-person launch events around the U.S, possibly hitting a city near you.  Sadly I will miss the Chicago launch event on November 20th, I’ll be at the MVP summit in Bellevue Washington. Not a bad trade-off though ;)  But if you’re in town, check out the Chicago event details and register quick before it fills up! And check back with the events site often because more cities will be opening up soon.

Agenda

image

Location

Drury Lane Convention Center

100 Drury Ln
Oakbrook Terrace Illinois 60181
United States

image

 

Some events are not listed on the events site yet, so here are some other cities coming on-line and a link to get registered:

12/3

Boston, MA

12/3

Nashville, TN

12/3

Bellevue, WA

12/4

Washington, DC

12/4

Philadelphia, PA

12/4

Miami, FL

12/5

Phoenix, AZ

12/10

Atlanta, GA

12/10

Denver, CO

12/11

Concord, CA

12/11

Harrisburg, PA

12/12

Sandy, UT

1/15

Los Angeles, CA

1/21

Mountain View, CA

0

October 30th, 2013 Edition of the Chicago Visual Studio ALM User Group: More Visual Studio ALM 2013 Goodness

by Angela 16. October 2013 14:34

http://www.tfswhisperer.com/image.axd?picture=image_60.png

If you attended the September meeting, this is not *quite* a redux.  I’ll be talking about a variety of ALM features, some that I covered at the Downers Grove meeting last month.  BUT this time around I will also be joined by 2 of my smarty-pants colleagues from Polaris.  Landan Rotter will be talking about the new integrated deployment tool, InRelease, and will be doing a hands-on demo for your enjoyment.  Chris Taylor will also do a deep dive on data driven CodedUI testing as well as an awesome walk-through of setting up Lab Management to support automated test execution! 

Visual Studio ALM 2013 tools are going to release THIS FRIDAY, October 18th, ahem, THIS THURSDAY October 17th, and the big launch is November 13th. If you’re interested in participating in the virtual launch event on November 13th, be sure to check out the VS 2013 Launch Site and sign up soon!  And in the mean time, get ready for what coming by learning more about what's new and cool. And if you can’t wait until RTM, you can still get downloads of TFS and VS 2013 RC today.

Parking downtown is a bit costly, but Aon parking is pretty reasonable if you get there after 4:30pm and leave by 10pm. Check out www.SpotHero.com, they might just save you some serious cash.

 

Meeting Date:  Wednesday October 30th

Agenda:    6:30 - Dinner, 7:00 Presentation

Location: Microsoft-Chicago 200 E Randolph, 2nd Floor, Chicago

Registration:      http://chicagoalmug.org/

 

PLEASE NOTE: Security is strict at the Aon center.  You MUST register as building security will NOT allow individuals to access the building without being pre-registered.  Their rules, not mine.

0

September 25th, 2013 Edition of the Chicago Visual Studio ALM User Group: Visual Studio ALM 2013

by Angela 17. September 2013 09:29

image

 

Well, with all the excitement of ThatConference, I skipped having an August meeting but we’re back! 

With the upcoming release of Visual Studio ALM 2013 tools, it seemed necessary to spend some time digging in! Jim and I will be spending this meeting talking about what's new and cool. We are still arm wrestling over who gets to demo what features, so for now just know it will be awesome! :)

And don't forget to get your fresh downloads of TFS and VS 2013 RC today. MSDN subscribers will also find everything they need through their Subscription site.  If you’re interested in participating in the virtual launch event on November 13th, be sure to check out the VS 2013 Launch Site and sign up soon!

Meeting Date: Wednesday September 25th

Agenda:6:30 - Dinner, 7:00 Presentation

Location:Microsoft-Downers Grove 3025 Highland Pkwy, Ste 300, Downers Grove

Registration:      http://chicagoalmug.org/ 

PLEASE NOTE: Security has gotten tighter at the Downers Grove building.  You MUST register as building security will NOT allow individuals to access the building without being pre-registered.  Their rules, not mine.

 

 

Speaker Bio:

Angela Dugan is the Polaris Solutions ALM Practice Manager. She focuses on TFS implementation and customization in the real world, Visual Studio related training and mentoring, and helping organizations to adopt Agile/Scrum methodologies. Angela had spent the previous 14 years as a custom application developer with a small consulting firm in Chicago, as well as did 5 years at Microsoft as an ALM evangelist. Catch up with her adventures on her blog.

Outside of wrangling TFS, Angela is an avid board gamer, an aspiring runner (up to 2.3 miles without vomiting!), and a Twitter addict. She lives in a 102 year old house in Oak Park that she is constantly working on with her husband David.

Jim Szubryt manages the application architecture team for the Enterprise Workforce at Accenture in Chicago. This responsibility includes managing the TFS Team that supports 2,500 developers in the global development centers. He has worked with the global teams on implementing ALM practices and his team is in the process of piloting TFS 2013.

He is also a Microsoft ALM MVP and a Microsoft Visual Studio ALM Ranger. He was project lead on the disaster recovery planning guidance that was published in March. Currently he is the Project Lead on the Ranger’s guidance for reporting with TFS 2012. Prior to becoming a project Lead he has written parts of the TFS 2012 upgrade guidance and the TFS Server guidance that are found on CodePlex.  His blog can be found here.

0

ALM Ruminations Part 2: TPS Reports and Writing Myself a New Pair of Fluevogs

by Angela 3. September 2013 17:58

Yes, Fluevogs. What? I don’t need a minivan!  My husband will find it amusing that I managed to get a plug in there for my favorite boots from the Fluevog fall lineup. It’s OK, I’ll stop talking about shoes now, read on...

If you’ve been following along with my ruminations about the process struggles and pop psychology required to survive software development, you may have already seen my first post. This is a follow-up, and I hope to have MANY more assuming I can find time between TFS installs Winking smile  So without further delay:

Favorite “Drive” quote #2: Goals that people [teams] set for themselves and that are devoted to attaining mastery are usually healthy. But goals imposed by others – sales targets, quarterly returns, standardized test scores, and so on – can sometimes have dangerous side effects.

So why do some managers cling to measuring their people by metrics like Lines of Code, # bugs fixed, and other archaic and easily gamed statistics? I can’t say for sure but I have some theories. One that I keep finding is that it’s often what they KNOW how to measure, and it makes them to feel like they have control over things. But sadly the accuracy of those metrics if often unreliable, at best. Add to that, their direct reports may have figured out how to work the system to meet artificially established goals, hiding issues, and masking discontent. Or perhaps software development management folks haven’t yet figured out what behavioral scientists have known for years - that creative work is actually HARMED by the use of extrinsic rewards systems.

Solving the first issue (bad metrics) is tough, how do you make someone see there is little value in many of the metrics that have traditionally been used since the beginning of IT? What SHOULD they be measuring instead? What are they themselves being measured on, and are those metrics effecting how they reward/punish the software team? I’m still working on perfecting how to address this one myself, and I often immediately point to the Dilbert where the software developer “codes himself a new minivan” as a wake-up call. Often times, it does not even occur to them that their cherished status reports might be at the root of the team’s problems.

The second point (hiding issues) is one I see even more often, where software teams themselves train managers that no matter how unreasonable a deadline, no matter how many times they change requirements, that the tem will double-down, work a lot of overtime and get it done. Even worse, most times the overtime goes unreported, and so any normal manager may conclude that any “small request” can be accommodated at the drop of a hat, and so will continue to do so. The team may be seen as a hero, but can also be seen as one that does not plan well, and is often scrambling to meet deadlines.  It is a double-edged sword. The team inevitably burns itself out trying to keep up, quality suffers in favor of getting features out the door quickly, and the manager often doesn’t get everything they wanted anyway. And no one is happy, not you, not the manager, and certainly not the customer. It’s lose-lose-lose situation and it doesn’t HAVE to be that way.

On the last point (squelching creativity), this is possibly the toughest of all to address, because again, most of us “IT folk” are not psychologists. Maybe your boss does not have an IT background, and simply does not understand that writing software is actually quite complex and difficult. You may have crafted hundreds of web pages, but that doesn’t mean that the 101st web page isn’t a totally different animal. God forbid the framework or tooling upon which you rely to build web pages has gone through a major upgrade recently!  I blame this on the inappropriate and overused comparison of software development to building a house. NO, NO, NO it is NOT just like building a house. And if you think the metaphor holds I doubt if you’ve ever actually written any software, or at least you haven’t in the last 10 years or so. Or maybe you want your software to turn out like just another plastic shoebox in a huge soulless fields of cheap Mc Mansions. Sure, in some cases the issue here is that IT management do not personally feel the pains or understand the challenges that the team is going through, or maybe they, in fact, are causing the pain… After all, the first step to recovery is realizing you have a problem in the first place…Seriously, we need an “agile intervention” offering complete with a 12-step program!

So if this sounds like where you work, buy your boss a copy of Drive and an anthology of Dilbert cartoons, and please stop training them to continue to give you unreasonable goals by working overtime and underreporting issues and bugs to make things look rosy. I promise you, that strategy may payoff in the short term, but in the long term nobody wins!

OK, I have a lot more spinning through my head but I think we’ve done enough navel gazing for this post. Stay tuned for more musings in the next week or so.

Tags:

ALM | Application Lifecycle Management | General | Process Methodology | SDLC | Scrum | development

0

A Continuation of My Ruminations on the Human Factor of ALM

by Angela 2. August 2013 12:41

Part 1: In the beginning

In my “And Now For Something Completely Different” series, I wax philosophical, almost literally, on human behavior. Now I’m hearing that Bjork song in my head. Anyone else? No? Just me? Ok then, moving on.

Now, before anyone thinks I’m some kind of behavioral science genius, I had quite a few of these realizations while reading “Drive: The Surprising Truth About What Motivates us” by Daniel Pink. Earlier this year at the ALM Summit, it seemed like every other speaker that I went to see recommended that book. And so I gave in and ordered it, hard to argue being that it was around $10 on Amazon. I also then spelunked into a deep rabbit hole of Wikipedia articles, scientific studies, and other related digital publications to see what the real experts had to say. And while nothing I read was specifically aimed at ALM, or even technology per se (except for the use of OSS to disprove money as a primary motivator), I found so many ideas that were EXTREMELY relevant to what I was doing in my day to day job. So this post will focus on the first major point of many that I dog-eared in the book.

Favorite quote #1: The best use of money as a motivator is to pay people enough to take the issue of money off the table. (and ditch the stupid contests!)

Intrinsic motivation. This is one of those things that you KNOW to be true, but you can’t quite put your finger on the why of it. I know I had that reaction whenever contests and incentives were announced at my previous job. I immediately groaned, rolled my eyes, and tried to think of the fastest way to produce the results they wanted while still doing all of the work that I saw as actually being valuable. You know, the stuff I am “graded” on during my end of year review.  Turns out, everyone felt that way too. And we never got the type of results from those silly contests that management was hoping for. It also felt like a form of punishment, as in, if you need to incentivize me with $500 do this, it must REALLY suck! Imagine our enthusiasm to take on that challenge? At the end of the day, money and rewards only get you so far, and too many bonuses and rewards can actually backfire and decrease motivation. People have to be internally motivated to WANT to do something for a strategy to realize long term success. Now I’m not a volunteer, mind you, I get paid very well at my new job, but I did leave a higher paying job to realign my career path with my passions. At the end of the day, the challenge of solving customers’ problems and making their lives better was driving my behavior. My passion is ignited and sustained by fresh, new problems and by having at least a little freedom to be creative in how I do my job. I should note that in most cases, I am speaking specifically from the perspective of a person working in IT so if you are in a vastly different line of work, you may not agree with all of my observations.

So back on track, my first thought was that this is yet another example of where agile is just a natural fit for software development. People enjoy challenge, and novelty, and need an environment that fosters that. Not that Waterfall based environments cannot provide freedom, novelty, and challenge (don’t laugh), but I have yet to find one that provided freedom, let alone the RIGHT kinds of novelty and challenge to promote a motivational environment. For instance, working 80 hour weeks for a month to make a deadline because of poorly planned milestones that you had no early visibility or input into is NOT a motivating challenge. And when the next 6 – 12 months of your life are scheduled, collated, and written in stone well, there goes freedom and creativity. Your focus now is on making dates, at any cost.

Because Agile and Scrum-based processes focus on self-direction, introspection, and continuous improvement, people get opportunities to constantly evolve and find new and more efficient ways to solve problems. Now that’s FUN. I’ve met few software engineers who don’t respond to that kind of motivation in a VERY positive way. After all, software development is as much of an art as a science. Despite all of the misleading comparisons to building a house, building software requires FAR more creativity and flexibility than framing a McMansion in the suburbs. And making software is HARD. The first time a Scrum instructor (Richard Hundhausen to be specific) uttered those words out loud, I kind of laughed, but then realized just how significant that statement was. Say it out loud with me and really think about it, “software development is HARD”. Sure there are hundreds of frameworks and software patterns out there to help you do it, but at the end of the day knowing how and when to use them, or even when to stray from them, is a really tough skill to master and requires constant recalibration.

Any artist will tell you that being confined by strict rules, and working under a heavily structured rewards and punishment system, stifles their creativity and narrows their focus. Working without freedom and with stifled creativity results in an inferior product, and an unhappy artist. It’s no different for software craftsman. At first I bristled a little at that term, “software craftsman”, but have come to embrace it as being a FAR more accurate label for what we do. Software is not churned out using repetitive and unchanging patterns like a Whopper. It relies as much on the right-brain as it does the left, and if it doesn’t for you, you might be doing it wrong.

Next we’ll talk about metrics. Hairs on the back of your next standing up? Did you get a little chill just then? I did.

Tags:

Application Lifecycle Management | Agile | Collaboration | Process Methodology | SDLC | development | Scrum

Powered by BlogEngine.NET 2.7.0.0
Original Design by Laptop Geek, Adapted by onesoft