Tag: linkedin

Categories
Business Intelligence Geeky/Programming Reviews

Microsoft Live Labs Pivot Viewer – Rich Internet Application

So, I previously blogged about using PivotViewer in your Web Applications, but you can also just consume Pivot collections using the “Pivot” tool from Microsoft Live Labs

You can download it here

What does this tool offer? Well first it has a library/homepage of collections you can browse

You can do some slicing and dicing on a collection of Presidents, or athletes, or Sports Illustrated covers. This tool and technology really fasinates me. It is “Business Intelligence” but in a different way – it is based on “objects” (images) instead of “metrics”. I like it.

What are some cool things I think this could be used for? Company Directory? Online Catalog? Beer selection at Eddie’s? the list goes on and on..

Additionally there is now an add in for SQL Server Reporting Services and SharePoint 2010 you can download here

Once I have an environment in which I can test that set up, I will blog about it.

Categories
Agile

Agile: Sprint

The sprint. The timeline of an agile team. The sprint is the “timebox” that you use to get your stuff done. It’s an iteration as you want to keep having sprints over and over.

You might have many sprints make up a release, you might have one sprint make up a release.

Your sprint could be a number of different timeframes.

I suggest 2 weeks.

Why 2 weeks? Well, it is enough time to get things done, but not have too much to worry about, it also ensures that things you want to get done are done in a small enough time frame so that the people that needs to see your outputs don’t have to wait longer than 2 weeks. 2 weeks also fits nice as 4 weeks could almost be considered 1 month.

Other alternatives? 3 weeks – might be the only other time frame I would suggest using, but then remember, if you have something get requested before a sprint, and you can’t get it into the current sprint, you won’t see that story completed for 6 weeks!

1 week is too short, you are just constantly churning. 4 weeks is another one that some teams use, but again, it could be 8 weeks before seeing something. The world just moves to fast for that kind of timeline.

Other options are doing staggered sprints. 2 2 3 2 2, or 2 3 2 3 2, etc. It can get confusing, but doable, I haven’t seen a reason to do it yet, so I have kept to the 2 week timebox.

I also recommend starting on a Tuesday, Wednesday, or Thursday. If you run your sprints say, from Tuesday, 2 weeks, you end up ending on a Tuesday afternoon. Same with Wed/Thurs. And you can do your Sprint Planning on that Tuesday/Wednesday/Thursday. When you use Friday and Monday, things just get tough to plan around. You probably never want to release on a Friday, people like to take vacations and days off on Fridays, tec.

Another tip, don’t treat a sprint like a mini-waterfall project. You will end up in trouble. Try to test/validate completed stories as they get completed by the do’ers. Waiting until the end of a sprint will lead to pile up of things to do.

Throughout the sprint, the product owners and requester of features should be in the loop (for one, with the Daily standup) but also they should be seeing the fruits of your do’ers labor, they should be seeing the output and features as they are completed.

Releasing at the end of the sprint is key. If you can’t, then you should at least have things in a “potentially shippable” state so you can demo and test it for the people that have requested it.

Other things you can do with your sprints. I like to separate out things into their own “mini sprint” when needed. An example might be, Upgrading your infrastructure to SQL Server 2008. You can’t really work on things on your servers when they are being upgraded, so at the end of a sprint, say “the next week is a mini sprint for the upgrade” and then pick up your regular sprint schedule after that. Same thing with holidays. Over the Christmas and New Year holiday you may have a 2 week holiday sprint. Just let your do’ers do research or something fun they have wanted to do. Most people will be out of vacation anyways.

Treat your sprint though like you would treat your daily standup. You don’t (you really can’t – or it screws up things) want to keep adjusting your days and length very often. The more you adjust the more it confuses people and the harder it is to try to get your actual velocity.

Pick a date to start, pick a timeframe, and stick with it. Try to stick with it for a year, at least 6 months before totally changing things up. Discipline, just like the daily 15 minute standups. Keeping things standardized and set helps your team and others know the schedule and keep things on track.


Categories
Ramblings

Foursquare in Your Business

I don’t own a business. So let’s just get that out of the way. But as a Foursquare user, and someone who frequents many businesses.. how could you use Foursquare as a business owner?

First, above all, you can know what the heck foursquare is… check it out.. http://www.foursquare.com .. ok, did you find your business on there?

Anyways, some places give discounts for mayors.. awesome. 15% at the local coffee shop for me, yet an employee is the mayor. Against the rules for places that give deals.

What else can you do? Well, you can know who is coming to your place. You can say “shout blahhhhhh” for a cool new badge

You can do other cool deals, like, the 100th checkin gets this, or the 10th checkin today gets this. Sky is the limit.

Foursquare, Gowalla, Yelp, etc. If you own your local business, you should be on there and know WTF is going on. Facebook – you should already be there. If not, for shame. It is 2010.

Engage your customers. Give them something, even if it is recognition, if they are utilizing these location based social apps with your business.

Your patrons will thank you and spread the word for you. Through twitter/facebook, or just word of mouth, for you.


Categories
Agile

Agile: Daily Standup, Daily Scrum

I hate meetings. Really, I do. They are toxic.

But one of the things your team needs to do is meet daily. With agile, it’s called the daily standup or daily scrum meeting. But what is it?

  • Every Day, 15 minutes
    The meeting needs to be every day. Every day (Monday-Friday). No Exceptions. No days off, no skipping, no excuses. Schedule it every day. 15 minutes. Try to get it in the same place
  • Stand up
    The reason it is called a “standup” meeting is that you need to actually stand up. Why? Because sitting down makes people take their time. Standing up makes people move faster, because they don’t want to stand for 60 minutes.
  • Three Questions
    What I did yesterday? What am I doing today? What’s in my way? Simple enough
  • Not Everyone
    You want your do’ers there, you want the scrum master and product owner, maybe some others, but not everyone needs to talk. Go around the room and the do’ers should give an update, others should just listen.
  • Details, but not too much
    Do’ers, when giving updates, should let team know what stories they are working on. If you use a virtual+physical board, you will have story #’s. Don’t just spout the numbers. Spout the numbers and the story title, and where you are at, maybe even burndown if you track that manually.
  • Keep on Track
    easy to get off track. Even with standing and whatever. Scrum master should make sure things keep moving. In, update, out, go. 15 minutes? Try to get done in 10.

Should you meet on your sprint planning day? I say yes.

What else does the daily standup bring us? Communication. Everyone should know what everyone else is working on, where things are at. People can’t hide. They need to give updates, they probably should have a good reason or be working on something else off sprint if they have no update.

What else does it bring? In my eyes: Discipline. Making sure you know what you did, what you are doing, and always meeting at the same time, and doing the same thing every day brings a little discipline to the team. Keeping things on track, 15 minutes, cruising through updates, instead of meeting speak and 60 minutes of babbling. It does good for everyone. It lets your do’ers get on with their day so they can keep burning down points!


Categories
Life

Europe

Last month, I was in Europe for a week on business. Madison to Chicago, To London to Milton Keynes, to Zurich, back to London and then to Chicago and Madison.

Was a real good trip (the business side, and seeing UK and Switzerland), but there were some things that just seemed.. well, weird.

Driving on the other side of the road.. yet using Miles instead of Kilometers in the UK. Also, instead of using “feet” for exits (Exit 1500 feet) they use Yards.. the only thing I know that uses yards is American Football. And that there are 3 feet in a yard.

GBP.. the pound. or lbs or # .. since I don’t have GB English keyboard setup. First off, the exchange rate is crazy, and then, the coins?! It was hard keeping all the denominations straight. 1 pence, 2 pence, 5 pence, 10 pence, 20 pence, 50 pence, 1 lb, 2 lb then 5 lb note and onward. Bills were too big for my wallet too.

The signs. “Give Way”, “Kill your Speed”, “Mind the Gap”. and so forth..

Sandwiches.. what is up with the sandwiches in the UK? Tons of different types and “flavors”. Odd for an American I guess.

Internet: no free wifi. Anywhere. UK or Switzerland. You pay by the hour, or 24 hours. What a rip.

Mobile service. Roming charges are through the roof, data roaming 20$/1MB – wtf! 50 cents an SMS..

Food.. proper english breakfast every day.. and for dinner, random things .. everything is similar to US, but slightly different. Just odd.

Country Pubs – loved these in the UK.. very laid back, my type of place.

Bacon. – wtf? real bacon is called streaky bacon. UK bacon is like, canadian bacon/ham ..kind of. Give me real bacon, any day.



Public transport – trains, the “tube” (subway) and other things, just way more advanced than here. Things are closer together, you can walk.

Roundabouts – there are like 6 in Sun Prairie, about 600 in Milton Keynes.

Beer – usually good beer on tap, no Bud, Miller, Coors, etc, etc. The crappy beer is good beer in the US.

Toilets – I never met one that flushed right, or some at all

TV – in the UK.. BBC 1,2,3 and Sky.. and thats it. In Switzerland, a few more channels, but after 11 PM, every commercial was an ad for .. well.. x rated things. Much different than USA

Zurich airport was the cleanest I have ever seen. Welcoming too.

Easyjet – boarding from the Tarmac

Downtown Zurich – very nice. Tons of bikes and walkers and train riders. Cobblestone walkways, just a good area.

Swiss Francs – worse that GBP. More denominations (1/2 francs?!?) and the conversion rate is horrible, not only that , but inflation rate is horrible. 2 beers for 17 francs? phhhh

Swiss.. most people can talk “baby” words in English.. Hi, Bye, Yes, No, Thanks, etc, etc.. some are real good at english, some have none. Your mileage may vary. If you go to a bar, just as for “Beer” and you might get something good, or bad.

Soccer – world cup was going on. I could hear vuvuzela’s everywhere i went from the TV’s having the games going.

Taxi drivers take credit cards in Zurich.

You can get Kangaroo and Ostrich Fajitas in Zurich..

There is a huge snow dome in Milton Keynes. You can go snowboarding any time of year.


The weather was nice, didn’t rain at all, 70’s.. but learn to convert Celsius to Fahrenheit.. since they all report in Celsius.

The iPad made it from Chicago to London, on the whole time, reading a book, and lost only 40% of the battery.

The trip was awesome, I had a good time, learned a lot about our business in Europe, met some great people, put faces to names, and just all in all had fun. The only downsides were, I missed my family and I wish had more time with each country and group in Europe. Two conflicting things!


Categories
Agile

Agile: Backlog

The product backlog. Not a ton to say on this right now, but here are some thoughts.

  • The current sprint is not backlog
    Seem’s obvious. But the backlog is the backlog. The current is sprint is what you are focused on and working on.
  • The next sprint is backlog
    yes, the next sprint, on your board, is still backlog. It is somewhat solidified, but it is in flux until when you start the next sprint as your current sprint.
  • Your backlog should be semi-full
    having nothing in your backlog means.. well, you have no backlog, and that isn’t good. You should have enough stories for 1-2 sprints. Having no backlog is like living paycheck to paycheck.
  • You should prune old stories
    Older stories that have been just living in your backlog, should get pruned. Either they are higher priority and should get done, or they aren’t worth doing. They might resurface later as something but they shouldn’t be carried along for months/years if they aren’t important enough to do.
  • Priority matters
    The product owner should make sure they have the backlog prioritized. An backlog that isn’t prioritized is just a stack of cards.
  • Split Backlog into buckets
    I like to split backlog into buckets. Technical vs Product, maybe Features vs Bugs, some way to differentiate things.
  • Try to get as much as you can scored
    You might want to try to score as many stories in the backlog as you can so you are always ready. Of course there is a balance. You want a full backlog, you don’t want 5000 items, and you don’t want to take 3 days scoring things. Score enough so that if you do get ahead you can take stories from the backlog to work on. Try to avoid scoring outside of sprint planning sessions.

The backlog is one of the most important parts of your Agile process. Without a backlog you don’t have anything to focus on as you move forward through iterations. Try to think of it as a well, a well you don’t want to dry up, but you don’t want to overflow either.

My preference is to have a product backlog and technical backlog. That ensures that technical debt isn’t ignored, but separates concerns as far as features that you might want to implement.


Categories
Life Work

Challenges: Stepping Up vs Running Away

Challenges. Every day, everyone faces some kind of challenge. From the most lazy point of view, “Can I get out of bed today”, to “Making it to work on time”, to also “Making sure my children are taking care of”, and “Making sure we have enough money”, and then with work, “Making sure we get this project done on time” to “Making sure we are under budget”, to things you might do in life, “Try to run 5 miles today” and “Do the half marathon” and also things like “Don’t eat the whole carton of ice cream” and “Stop smoking” and the list goes on and on. You get it, there are an infinite number of challenges in life, no matter what you do or who you are.

It is what you do when faced with them that defines you.

What can you do? Well, you can walk (or run) away from challenges. It is the easy thing to do really. Just give up, walk away, go on to something easier, don’t get out of bed, don’t finish that project, light up the cig.

Or, you can step up to the challenge. You can take the mountain of problems facing you (don’t worry – everyone else has their own mountain) and you look at it as opportunity. Start figuring out how to make things easier, change processes, get things done and keep a level head, always looking ahead to the progression of what you are doing and how it will make things easier for yourself going forward.

There aren’t many challenges that can’t be stepped up to, and worked on, and overcome. Ask any survivor, or anyone that was ever told “no, you can’t do that”, or “it can’t be done”.

In the face of hard work and adversity, the people that rise to the challenge to get things done and still handle themselves are the ones that move forward. The ones that run away, sure they will continue on a path, but they missed something. That big mountain of opportunity to take and do something with.

One of my favorite movies is “Prefontaine“. Pre was an awesome runner. In the movie, he wants to run the one mile so bad, it is all he can think about. Being the one mile champion, having the best time, etc etc.

Before season starts, the coach, Bill Bowerman (of Nike fame – played greatly by R. Lee Ermey) – says something like, “Pre, you are never going to be the best miler, but you could OWN the three mile, make it your race“.

Yes, that is the quote. “Make it your race”. Being a huge runner in my heyday, I love that quote. Take your opportunity that is staring you in the face, even though it may be tough, you might not like it or it doesn’t seem like something you want to do, and make it your race. Make it yours. OWN it. Be awesome at it. Show everyone that you can do it, and make a pile of problems into your golden opportunity.

Make it your race.


Categories
Agile

Agile: Stories

In Agile, there is the concept of “stories” or “User Stories”. What are stories? Well, maybe it is best to look at what they aren’t:

  • They aren’t projects
    Stories are smaller than projects, by a long shot. A group of related stories is called an “Epic” but even then an “Epic” isn’t a project. But again, it all depends on how you or your organization defines a “project”. An agile team can focus on one project throughout their entire lifetime. Another might work on multiple projects, it all depends on how things are set up. But stories aren’t projects. Projects are made up of stories.
  • They aren’t tasks
    Stories should be bigger than tasks. Each story should really take a few to many tasks to complete. You can get into the mindset of breaking up everything into tasks, but then you might be going to granular. You want your stories to be small enough to get completed within your sprint, but also big enough to not take 10 minutes to complete.
  • They aren’t direct requests
    What do I mean by direct requests? A direct request from and end user or customer doesn’t directly relate to a story, it usually ends up being multiple stories. In the case where the request is just one story, it probably should be reworked to fit the mold of a story.
  • They aren’t features
    They might be feature requests, but like “direct” requests, usually a feature request ends up being multiple stories, or if the request is small enough to be one story, it needs to be reworked to become a story.
  • They aren’t bugs
    same as direct requests and features.
  • They aren’t day to day operational actions
    Some people might get into the mode of “well, we do this every day, so it should be a story”. No… it shouldn’t. It should be what you do day to day. Your velocity will get adjusted by your do’ers doing things day to day, but you shouldn’t storyize day to day things. Would you create a story for your commute? For reading email? For lunch? The only thing you might want to storyize is an architecture type meeting, where the deliverable is a bunch of stories. I like the idea but I’m not 100% sold on it yet.

Well, so there is a short list of things stories aren’t. So what are they?

As a user/group/xyz, I would like new feature/bug fixed/thing done, for this reason/business value.

I would say the most key part of that story format is the end. The business value. Without that you are spinning your wheels, you don’t know why you are doing something.

What about things that go along with a story?

You might write the # of a record in your virtual system to easily correlate. Depending on your process, you might hand write cards (I personally like this method). Or you might print them. What about other notes? As a developer or do’er you might write things on the back of the card for when you pass to QA or the validation of the story, or just to keep things in the open. If you use a virtual system, you might have extra notes or background info so the do’er can actually do it.

I like to have a small title, and then the story.

Example,

As a sales executive, I would like to be able to see my sales and goals by product and year so I can better analyze my commissions.

A title might be “Adding goals/sales to cube for sales”

I also like to have a “component” when working on a team with multiple mini projects that might be getting done. “Sales Cube” might be a good component for the story above.

What else do stories have? Priorities and Scores. More on that later..


Categories
Geeky/Programming Product Reviews

Thoughts on the iPhone 4

I picked up my iPhone 4 on Friday afternoon (July 16th). Wonderful device. Retina display is awesome. Video camera, front facing camera, flash: awesome.

People wonder about the dropped calls, etc. Whatever. First, I may be different. I haven’t even USED the phone yet. I don’t really use the iPhone as a phone. Personal Handheld Online News Entertainment ? Who knows.. I use it for everything but a phone. Maps, Reading, Feeds, Twitter, Facebook, News, Movies, Games, Work, Email, etc, etc, etc. It isn’t a phone. 🙂

Any ways, Steve Jobs already told us that we are getting bumpers, I might use it.

This device is the best out there, by far. Most gripes might be with AT&T, not Apple. Like others have said, build a better device, and then we will see. I don’t see it yet. I have tried other devices and they just aren’t as smooth.

I can’t wait for Emily to get hers so we can do the FaceTime thing, that will really be awesome.


Categories
Agile

Agile: The Story Board

The story board…

If you have used Agile for Project Management or Software Development, and used Scrum, you probably have heard of the “Story Board”.

Trek BI Agile Story Board

Funny thing though, I have talked to a few people that have came through and they saw the boards we have and it was “oohh I have never seen one in real life”.. but yet they have run or been involved with scrum before.

So what is the deal with the “board”?

  • The Board is a focal/gathering point
    Every day at your standup/scrums, you should bring the board in and use it as a tool. Also at the sprint planning. Think of it as another team member. Talk to it. Talk in front of it, analyze it, adjust it, show it off, explain things on it to people
  • The Board shows tangible evidence of results
    You should hang your velocity and burndown charts on the board, you should have a nice full current and next sprint that changes every day as people do things and new items get prioritized. Your backlog should be filling up. Communicate your iteration dates and maybe other key info, but most important, if someone walks up, they can see your burndown.
  • The Board is a talking point
    People around the office start asking “What is that thing?” People in other teams want to know what is up. Other people might come up and ask where things are at, or where their “story” might be. You can use the board to start discussions on agile and also about your project
  • The Board let’s your focus
    As a developer or “do’er” for your project, you can focus on just the current sprint. You can focus on the cards on the board. You see slightly what might be coming in next sprint, but you are focused. As a product owner or team lead, you can see progress and focus on the current 2 weeks.
  • The Board makes it tough for distributed teams
    If your team has some members off site part of whole of the time, then it is harder for them to actually “use” the board. They need a virtual board as well. They need virtual stories or some way to update progress.
  • The Board adds a little overhead for Scrum Masters
    With a online system or virtual system, the Scrum master can update things there, and so can the developers. With a board, and especially with a board + virtual system, the scrum master has to make sure things are in sync. What should they focus on? The board or the virtual system? Both. But since the board is visible to EVERYONE who might walk by, they need to make sure it is up to date and in working order.

My thoughts: The board *should* exist, you *should* use a board.

But, what if you run distributed teams? Then.. if majority of them are not on site, then use a virtual board. If it is a mix, use a physical and virtual board.

But what if we don’t have room for a board? Then make room.

But a board costs money. Not really. I made one out of things lying around the office. Minimal cost. You can expense story cards, etc.

But xyz.. well, I am sure there is an answer.

If anything, start with a board, and cards (another blog post on that) for at least one year, and then look at going virtual, *if it makes sense*. I still think the use of the physical board is a key part of the process, but like with anything Agile, the process always differs by team and project.

You can always roll the board somewhere to demo. You can show the board to anyone. Any worker, any executive, a group of many people, or small. You might not be able to do that with a virtual system: you might be limited by number of accounts or other system limitations.

The board might be a “relic” of agile, but I think it lends itself to running the process in a way many can understand, without having to learn any software, and also lets your team communicate progress and results easily. Use a board? Just do it.